The quota burns faster than the bill

Business Challenge

A team sizes a Bedrock workload from the price list, doubles it for safety, and ships. Within a week it is returning throttling errors while the bill sits at a fraction of the budget.

The instinct is to look for a billing error, then for a leak. There is neither. Quota and cost are both counted in tokens, and they are consumed at different rates — so the number you budgeted and the number that throttles you were never the same number.

1The quota and the bill are different currencies

AWS defines a “burndown rate” — “the rate at which input and output tokens are converted into token quota usage for the throttling system.” For output tokens it is not 1:1.

“The burndown rate for Anthropic Claude models version 4.8 is 15x for output tokens… and the burndown rate for Anthropic Claude Opus 5.5, Claude Sonnet 5, Claude Opus 5, and Claude Fable 5.1 is 10x… For all other Anthropic models version 4.7 and below, the burndown is 5x… For all other models, the burndown rate is 1:1.”

And then the sentence that separates the two currencies entirely: “You're only billed for your actual token usage.”

Fix

Budget cost from the price list and capacity from the burndown rate. They are not convertible.

2max_tokens is spent before the model writes a word

Quota is deducted on the way in, not on the way out: “At the start of the request – The following sum is deducted from your quotas… Total input tokens + max_tokens. The request is throttled if you exceed a quota.”

So max_tokens is a reservation, and an optimistic one is paid for in concurrency. AWS's own worked example sets it to 32,000 against a response that turns out to be 1,000 tokens: “Initial deduction when request is made: 36,000… Final adjusted deduction after response is generated: 9,000.”

That is four times the quota the completed request actually used, held for the duration and unavailable to anything else.

Fix

Set max_tokens to the size of the answers you actually get, not to the model's ceiling.

3The obvious escape hatch is shut for the models you want

The answer to throttling is supposed to be Provisioned Throughput — buy capacity, stop being throttled. But the list of models you can buy it for is not the list of models you are using.

On the supported-models page, the newest Anthropic entry is Claude 3.5 Sonnet v2. The models carrying the 15x and 10x burndown rates — the ones whose quota cost is highest — do not appear on it at all.

Region coverage narrows it again: most entries are single-Region, and every Claude 3.5 Sonnet variant is us-west-2 only.

Fix

Check the supported list before designing around Provisioned Throughput. It is not a general escape.

Architecture

The useful frame is two products, not one product with two prices.

Diagram: the two Amazon Bedrock capacity products and the different way each one fails. On the left, on-demand inference, where you are throttled by a tokens-per-minute quota set at the model level. A request deducts its total input tokens plus its max_tokens value at the start, before the model generates anything, and the request is throttled if that sum exceeds the quota. When the response is finished the deduction is adjusted to input tokens plus cache write tokens plus output tokens multiplied by a burndown rate, and cached read tokens are not counted toward the quota at all. The burndown rate is fifteen times for Claude 4.8 output tokens, ten times for Claude Opus 5.5, Sonnet 5, Opus 5 and Fable 5.1, five times for Anthropic models version 4.7 and below, and one to one for all other models, while billing remains one to one throughout, so quota and cost are consumed at different rates. A panel gives AWS's own worked example, where a request of one thousand input tokens generating one hundred output tokens on Claude Sonnet 4 depletes one thousand five hundred tokens of quota but is billed for one thousand one hundred. On the right, Provisioned Throughput, bought in model units where each unit delivers a set number of input tokens per minute and output tokens per minute, with the note that the actual figure per model unit and its price are not published and require contacting an AWS account manager. Its commitment terms are no commitment, deletable at any time, one month, and six months, where a committed purchase cannot be deleted before the term completes. A closing panel records that the commitment renews automatically at the end of each term, that cancelling auto renew still charges the full fee for the current term whether or not inference runs, that auto renew cannot be re-enabled once cancelled, and that no further modifications are possible for the remainder of the term. — On-demand fails on quota, which you can measure. Provisioned fails on commitment, which you cannot exit.

On-demand: the limit is not the one you budgeted

The arithmetic at the end of a request is precise, and every term in it matters: InputTokenCount + CacheWriteInputTokenCount + (OutputTokenCount x burndown rate).

AWS works it through: 1,000 input tokens producing 100 output tokens on Claude Sonnet 4 means “1,500 tokens (1,000 + 100 x 5) will be depleted from your TPM and TPD quotas” while “You'll only be billed for 1,100 tokens.”

Push that to a generation-heavy workload on a 15x model — 1,000 in, 1,000 out — and the request burns 16,000 tokens of quota while billing 2,000. Eight times as much quota as cost, for the same request.

One term in that formula runs the other way

“CacheReadInputTokenCount don't contribute to this calculation and are not counted toward your quota.” Prompt caching is usually filed under cost reduction. It is also the only lever in the formula that buys back throughput, because a cache read is free against the quota as well as cheaper on the bill. On a workload with a large stable prefix, that is the difference between being throttled and not.

Provisioned Throughput: a reservation, priced privately

Capacity is bought in Model Units. An MU “delivers a specific throughput level for the specified model” — a number of input tokens per minute and a number of output tokens per minute.

What those numbers are, AWS does not publish: “For more information about what an MU specifies, pricing per MU, and to request limit increases, contact your AWS account manager.”

That is worth sitting with, because it decides how this post can honestly end. The break-even between on-demand and provisioned is a function of the throughput one MU delivers and what it costs, and neither is public. Nobody can compute that break-even from the documentation — not me, and not you. It is a conversation with an account team, and any blog post that prints a crossover point for it is printing a guess.

Why This Architecture Holds Up

The commitment is a one-way door with a default that closes it again

The three terms look like a normal discount ladder: “No commitment – You can delete the Provisioned Throughput at any time. 1 month – You can't delete the Provisioned Throughput until the one month commitment term is over. 6 months – You can't delete… until the six month commitment term is over.”

The part that is not a normal discount ladder is what happens next: “Your Provisioned Throughput will automatically renew at the end of each commitment term.” A six-month commitment is not a six-month decision unless somebody diaries it.

And the exit is itself irreversible

Cancelling auto renew does not stop the current bill: “you will still be charged the full provision fee for your current term, whether you run inference or not.” It also freezes the resource — “you can't make any further modifications to your Provisioned Throughput for the remainder of the commitment term” — and it cannot be undone: “Auto renew cannot be re-enabled after it is cancelled.” So the sequence is: commit, forget, renew, cancel, and then run six months of a resource you can neither resize nor stop paying for. Every step of that is documented and none of it is an error.

Two endpoints, two quotas, one model

A detail that will confuse exactly one incident per organisation: “Amazon Bedrock offers two inference endpoints – bedrock-runtime and bedrock-mantle – each with its own per-model quota allocations. Traffic to the two endpoints is tracked against separate quotas, even when calling the same underlying model.”

Burndown does not cross over either: it “applies only to models available on the bedrock-runtime endpoint”, while mantle-only models “have separate quotas for input and output tokens, so burndown does not apply.” Two services' worth of capacity behaviour behind one model name.

Customisation removes the choice

One line collapses this entire decision for anyone fine-tuning: “If you customized a model, you must purchase Provisioned Throughput to be able to use it.”

So a custom model is not a model change, it is a billing-model change — from per-token to hourly, “Billing continues until you delete the Provisioned Throughput.” The cost of fine-tuning is not the training run; it is the floor under every hour afterwards. And in GovCloud (US-West) it is the only thing supported at all, “only for custom models with a no-commitment purchase.”

Key Architecture Decisions

Decision	Choice	Reasoning
Capacity planning input	Burndown rate, not price	Output tokens burn up to 15x quota while billing stays 1:1.
`max_tokens`	Sized to real completions	Deducted in full up front. AWS's example reserves 36,000 for a 9,000 request.
Prompt caching	Treat as a capacity lever	Cache reads are not counted toward quota — the only term that gives throughput back.
Model choice	Check burndown before benchmarking	A 15x model and a 1:1 model need different quota headroom at the same spend.
Provisioned Throughput	Only with an account-team number	MU throughput and price are unpublished; no break-even is computable without them.
Commitment term	No commitment until measured	1 and 6 month terms cannot be deleted early, and renew automatically.
Auto renew	Diarised before the term ends	Cancelling is irreversible, still bills the full term, and freezes modifications.
Fine-tuning	Budget the hourly floor, not the run	A custom model cannot be invoked without Provisioned Throughput.

The measurement worth taking first

Before any of this is a capacity decision, it is an observability one. The burndown formula is built from CloudWatch metrics you already have — InputTokenCount, OutputTokenCount, CacheReadInputTokenCount, CacheWriteInputTokenCount — so the quota cost of your real traffic can be computed rather than estimated.

Do that before comparing it to anything. A workload whose output-to-input ratio is small is barely affected by a 15x multiplier; one that generates long answers from short prompts is dominated by it. The same spend produces completely different capacity profiles, and only the metrics know which one you have.

Closing Thought

The pricing page answers one question well: what will this cost per token. It is silent on the question that actually stops a launch, which is how much of it you are allowed to do per minute.

Those two are related by a multiplier that lives on a different page, applies to only some models, changes with model version, and runs as high as fifteen. A team that reads only the first page will budget correctly and still be throttled, and every instinct will point at the bill, which is the one thing that is behaving exactly as documented.

The honest conclusion of a cost-lens post is usually a number. This one cannot be, and that is the finding: the crossover between on-demand and provisioned depends on two figures AWS publishes to account managers and not to documentation. What you can do without them is measure the quota cost of your own traffic, which is computable today, and refuse to sign a six-month commitment against a break-even nobody can show you.

Next in this series

AI & ML — vector storage for retrieval: OpenSearch Serverless, pgvector on Aurora and S3 Vectors, what each one costs at rest versus at query time, and why the cheapest place to keep embeddings is not always the cheapest place to search them.

AWS Architecture Series #62 — The quota burns faster than the bill