Research-backed calculator guide

Amazon Bedrock Provisioned Throughput Cost: Model Units, Commitments and Break-Even

Learn how Amazon Bedrock Provisioned Throughput cost is built from model units, hourly commitment terms, utilization, and an explicit on-demand break-even model.

What you are paying for

Provisioned Throughput reserves a higher throughput level for a model at a fixed cost. In the model-unit form, each MU represents a specified input-token and output-token capacity over a one-minute span for the selected model. That means an MU is not a portable unit of “LLM compute,” and it should not be compared across models without the model-specific capacity definition. Two MUs on one model may not imply the same request rate as two MUs on another. ^[1]

The bill has four inputs:

1. Model and Region. AWS publishes supported combinations separately, and the current supported-model page lists model IDs and Regions rather than one universal catalog. Check that page before using a price from a different model or Region. ^[4]
2. Capacity. Enter the number of MUs, or the input/output token-per-minute reservation when the account offers token-based Provisioned Throughput. ^[3]
3. Term. A no-commitment purchase is more flexible. One- and six-month model-unit terms can lower the hourly rate but leave you paying for the committed capacity even when demand drops. ^[1]
4. Time active. An MU is charged while the Provisioned Throughput exists. A month is not necessarily 730 hours: AWS’s published example uses 31 days, or 744 hours. Use the calendar term or your contract’s billing convention instead of silently substituting 730.

This structure is different from on-demand inference, where the main inference meter is generally input and output tokens. It is also different from batch or other inference options. If your traffic is spiky, still changing models, or easy to defer, a fixed hourly commitment can create a large under-use charge even if the nominal MU price looks attractive.

Model units versus token-based Provisioned Throughput

The AWS purchase documentation explicitly describes two types: Provisioned Throughput by Tokens and by Model Units. The purchase flow therefore matters. For a model-unit purchase, you specify MUs and a commitment. For a token-based purchase, the planning unit is configured input and output token capacity. Do not use an old MU rate table as a proxy for a token-based reservation, and do not treat a token reservation as an interchangeable model-unit quote. ^[3]

A model-unit worksheet is most useful when the capacity contract is genuinely model-unit based. A token-based worksheet should instead compare committed input and output tokens per minute with observed p50 and p95 demand, plus the cost of any traffic outside the reservation if the applicable product behavior allows it. Confirm the current behavior and pricing with AWS before making a purchase.

Worked cost example

The following calculation uses the public AWS pricing example for Amazon Titan Text Express. AWS lists two MUs at $18.40 per hour per MU for a one-month commitment and calculates the term with 31 days. The table makes each step inspectable.

This is a fixed-capacity estimate. It does not say that the two MUs will process a particular number of tokens, because AWS’s public guidance makes the MU throughput model-specific. It also excludes any unrelated Bedrock services, data transfer, logging, storage, customization, guardrails, retrieval, or application costs. The $27,379.20 figure is the arithmetic for the published example, not a quote for your account.

A break-even sensitivity case

To show how an on-demand comparison works without inventing a vendor quote, use explicit assumptions. Suppose a team measures 10 million input tokens and 2 million output tokens per day for 31 days. For this sensitivity case only, assume an on-demand rate of $0.80 per million input tokens and $1.60 per million output tokens. Replace both rates with the live price for your selected model, Region, and tier before making a decision.

• Input: 10M × 31 × $0.80/M = $248.00
• Output: 2M × 31 × $1.60/M = $99.20
• Assumed on-demand total: $347.20 per 31-day month
• Published two-MU commitment example: $27,379.20 per 31-day month

At that assumed traffic level, the commitment is not close to arithmetic cost parity. Keeping the same 5:1 input-to-output mix, the on-demand spend would need to scale by 27,379.20 ÷ 347.20 = 78.86. That implies about 789 million input tokens and 158 million output tokens per day before the two figures meet on price alone.

This is a sensitivity result, not a recommendation. It omits the value of predictable capacity, the cost of throttling or latency failures, and the actual MU capacity. Conversely, it also omits the risk that demand falls below the assumed average. A capacity purchase can be sensible even when its token-only arithmetic is higher if the workload has a measured throughput requirement that on-demand cannot meet. The decision needs both economics and a capacity test.

How to calculate your own Bedrock PT cost

Start with a usage window long enough to show peaks and quiet periods. Export input and output token counts, requests per minute, response latency, throttling, model ID, Region, and the inference path. AWS notes that Bedrock quotas are account- and model-sensitive, and that some models are controlled by token quotas while embedding models use requests per minute. Treat the quota shown in your account as an input to sizing, not as a universal default. ^[5]

Then run three scenarios:

• Low utilization: the committed capacity is active but lightly used. This shows the cost of idle reservation.
• Expected utilization: the measured sustained workload. This is the base case for comparing fixed capacity with on-demand.
• Peak utilization: the largest sustained interval you need to serve. This tests whether additional MUs or another inference path is required.

For each scenario, calculate capacity cost, tokens actually processed, and effective cost per million processed tokens. The last metric is term charge ÷ processed tokens × 1,000,000, separated for input and output if the meter treats them differently. Do not call that an AWS price: it is your realized cost after under-use.

Next, request the current model-specific pricing and MU throughput definition. AWS’s supported page can confirm whether a model and Region are eligible, while the purchase page explains whether the account flow is by MUs or tokens. ^{[3] [4]} If the model-unit capacity is not publicly specified, record the value from your account-team quote or service documentation and retain the quote date. Never fill the gap with a rate from a different model.

Finally, compare the commitment with alternatives. Use the model pricing comparison when the model choice is still open. If the workload is retrieval-heavy, separate inference from retrieval and embeddings with the RAG cost calculator. If you are comparing managed capacity with operating your own serving layer, the self-hosted GPU inference cost calculator provides a different capacity-cost baseline. An agent that triggers multiple calls should also be decomposed before you use a single average request.

Commitment, cancellation, and under-use risks

The main operational risk is confusing a lower hourly rate with a lower total cost. If you commit for six months and use one MU for only a few hours each day, the discount does not recover the idle hours. A no-commitment purchase may cost more per hour but preserve an exit when the model, Region, or product changes.

AWS says a model-unit Provisioned Throughput with a commitment cannot be deleted before the commitment ends. For token-based Provisioned Throughput, cancelling auto-renewal leaves the service active through the current term and the full provision fee remains due whether or not you run inference. Auto-renewal is also a separate control that should be checked during procurement. ^[6]

Model eligibility can change as product catalogs change. The supported-region page should be treated as a dated lookup, not a permanent guarantee. A price copied from a blog, a different Region, or an older model card may be useful for historical context but should not be used as a current quote. The official AWS pricing page also says to contact the account or sales team for more details on model units. ^[2]

FAQ

Is Amazon Bedrock Provisioned Throughput billed per token?

Not necessarily. Model-unit Provisioned Throughput is billed hourly for the capacity you purchase, while AWS also documents a token-based Provisioned Throughput type. Identify the purchase type, model, Region, and term before choosing a formula. ^{[1] [3]}

What does one Bedrock Model Unit include?

An MU represents a specified throughput level for a particular model. AWS describes that level using input tokens and output tokens processed per minute, and notes that the details are model-specific. One MU should not be assumed to have the same capacity across different models. ^[1]

Does unused Bedrock Provisioned Throughput still cost money?

Yes, the fixed provision fee continues while the capacity exists. The cost example above is charged by hours in the term, not by the number of tokens successfully processed. That is why realized cost per million tokens rises when utilization falls.

How do I find the Bedrock Provisioned Throughput break-even point?

Use the equation fixed term cost ÷ on-demand cost per unit of measured usage. In practice, calculate on-demand input and output spend from your observed traffic, then solve for the traffic level at which that spend equals the fixed commitment. Keep capacity sizing separate: an arithmetic break-even does not prove that the selected number of MUs can serve the peak.

Can I delete a committed model-unit purchase early?

AWS says you cannot delete a model-unit Provisioned Throughput with a commitment before that term is complete. For token-based Provisioned Throughput, you can cancel auto-renewal, but the current term and fee continue. Confirm the exact purchase type and controls in the console before approval. ^[6]

Should a new application start with Provisioned Throughput?

Usually, first measure the workload on a flexible path, validate the model and Region, and establish a sustained throughput floor. Provisioned Throughput becomes easier to defend when the model choice is stable, utilization is observable, and the cost of capacity failure is explicit. That is a decision rule, not a promise that one inference mode is cheapest for every workload.