Bedrock Provisioned Throughput: Working Out Whether It Pays

#ai #llm #machinelearning #programming

Provisioned Throughput is Bedrock’s fixed-capacity option: you pay by the hour for a reserved slice of a model instead of by the token. Whether that is cheaper than on-demand is arithmetic, but two of the inputs are not on any public page — so this is the formula, and an honest account of what you have to go and ask for.

What a model unit is

You buy Provisioned Throughput in model units (MUs) for one specific model, using CreateProvisionedModelThroughput, and you are billed hourly from creation until deletion whether or not you send traffic. AWS defines an MU as delivering a specific throughput level for that model, expressed as two things: the number of input tokens it can process across all requests in one minute, and the number of output tokens it can generate across all requests in one minute.

A provisioned model is then addressed by ARN. You pass arn:aws:bedrock:us-east-1:111122223333:provisioned-model/abcdefghij12 as modelId on Converse or InvokeModel, and that request is served from your reserved capacity rather than the shared pool. Three constraints follow from the design and are worth knowing before you cost it out:

A custom model requires it. AWS states that if you customised a model you must purchase Provisioned Throughput to use it. For that case there is no break-even to compute — it is the price of admission.
Batch cannot use it. AWS documents that batch inference is not supported for provisioned models, so you cannot park overnight work on idle reserved capacity. Your batch jobs keep paying batch rates.
Inference profiles cannot use it. AWS states that inference profiles do not support Provisioned Throughput, so you cannot combine reserved capacity with cross-region routing. Those are two different answers to a capacity problem, not two halves of one.

The two numbers AWS does not publish

Here is the part that most articles on this subject quietly invent. AWS’s Provisioned Throughput documentation says, of what an MU specifies and what it costs: for more information about what an MU specifies, pricing per MU, and to request limit increases, contact your AWS account manager. The Bedrock pricing page carries hourly Provisioned Throughput rates for some models and not for others, and the throughput an MU delivers is not stated per model anywhere public.

So the two inputs you must obtain, and the exact names to use when asking, are:

The hourly price per model unit for your model, in your Region, at each commitment term you would consider.
The tokens per minute one MU delivers for that model — input and output separately, because they are different numbers.

Everything below is a derivation, not a quotation. The symbols are filled with clearly hypothetical values so the arithmetic is followable; they are not AWS prices and must not be used as estimates. Substitute the figures your account team gives you. Documented facts on this page — the MU definition, the commitment terms, the batch and inference-profile exclusions — come from AWS’s Provisioned Throughput documentation as published in August 2026.

The break-even formula

Provisioned capacity is a fixed cost per hour; on-demand is a variable cost per token. Break-even is the hourly token volume at which the two are equal. Write it with the output side dominant, because on most models output is priced several times above input and reserved capacity is usually sized by output:

Let
  P_mu    = hourly price of one model unit          (from your account team)
  N       = model units purchased
  R_in    = on-demand price per input token
  R_out   = on-demand price per output token
  T_in    = input tokens you would send per hour
  T_out   = output tokens you would generate per hour

On-demand hourly cost   C_od  = T_in * R_in + T_out * R_out
Provisioned hourly cost C_pt  = N * P_mu

Break-even is C_od = C_pt, i.e.

  T_in * R_in + T_out * R_out = N * P_mu

Holding the input:output ratio at k = T_in / T_out:

  T_out = (N * P_mu) / (k * R_in + R_out)

Worked with hypothetical numbers, to show the shape of the answer. Suppose one MU costs 40 currency units per hour, on-demand input costs 3 per million tokens and output 15 per million, and your traffic sends four input tokens for every output token. Then:

k       = 4
R_in    = 3 / 1_000_000   = 0.000003
R_out   = 15 / 1_000_000  = 0.000015
N       = 1
P_mu    = 40   (HYPOTHETICAL — not an AWS price)

T_out = 40 / (4 * 0.000003 + 0.000015)
      = 40 / 0.000027
      ≈ 1,481,000 output tokens per hour

with T_in = 4 * T_out ≈ 5,926,000 input tokens per hour

Roughly 1.5 million output tokens an hour, every hour, before the fixed cost wins. That is the useful shape of the result even though the inputs are invented: break-even is a sustained rate, and the units are tokens per hour, not tokens per month. A workload producing forty million output tokens a month sounds enormous and is nowhere near break-even if it arrives in a two-hour window each weekday.

That is the whole reason this calculation surprises people. On-demand bills the area under your traffic curve; provisioned bills the rectangle around it. Utilisation is the entire argument, and utilisation = actual tokens per hour / (N × tokens per MU) is the number to compute before the price.

What a commitment term does to the answer

AWS offers three commitment levels and documents that a longer commitment gives a more discounted hourly price:

No commitment — deletable at any time. The only option that lets you test the calculation against reality without betting on it.
1 month — AWS states you cannot delete the Provisioned Throughput until the term is over.
6 months — the same, for six months.

The undeletable part is the risk, and it is asymmetric in a way the hourly discount does not capture. Billing continues until you delete, and you cannot delete inside the term, so a six-month commitment on a model that a provider supersedes in month two is six months of paying for capacity on a model you no longer want to serve. Weigh the discount against how confident you are that this specific model id is the one you will still be routing to. A no-commitment purchase held for a month costs more than a one-month commitment and tells you whether the workload is as flat as your dashboard suggested.

Reasons it still loses

Even where the arithmetic works, three things frequently make Provisioned Throughput the wrong instrument:

The problem was a spike, not a level. If you are here because of ThrottlingException at peak, reserving enough MUs to absorb the peak means paying for the peak all night. Cross-region inference and a retry policy are usually the cheaper answer to burstiness.
It buys one model in one Region. Reserved capacity is not fungible. Two models, or one model in two Regions, is two purchases, and utilisation is computed separately for each.
Half your traffic is deferrable. Work that can wait belongs in batch, which is priced well below on-demand and is excluded from provisioned capacity anyway. Moving it first shrinks the synchronous curve you were about to reserve against — frequently below break-even.

If you have not yet worked out what your current on-demand spend actually is per model, do that first; reading the Bedrock price list gives you R_in and R_out, and your token counts come out of the usage block on every response.