By default, calling Claude on Bedrock is on-demand: you pay per input and output token consumed, with no standing cost, and your throughput lives under shared per-account quotas. Provisioned Throughput is the alternative purchasing model: you buy dedicated capacity in units, pay a fixed hourly rate whether or not you use it, and get a guaranteed throughput level in return. It is the Bedrock analogue of reserving instances instead of running on-demand compute.
Model Units and commitment terms
Capacity is sold in Model Units (MUs). Each MU delivers a defined level of throughput, specified as input tokens per minute and output tokens per minute for the model you provision. You choose a commitment term: no commitment (hourly, cancel anytime), 1 month, or 6 months — the longer the commitment, the lower the hourly price. Custom models on Bedrock require Provisioned Throughput to run at all and are priced at their base model's rate.
| On-demand | Provisioned Throughput | |
|---|---|---|
| Billing | Per token consumed | Per hour per Model Unit, regardless of use |
| Capacity | Shared, bounded by account quotas | Dedicated, defined per MU |
| Idle cost | Zero | Full hourly rate |
| Commitment | None | None / 1 month / 6 months |
When it makes sense — and when it doesn't
The economics are a base-load question. Provisioned Throughput pays off when you have a high, steady baseline of traffic: the hourly fee is a fixed cost, so the more fully you use the reserved capacity, the cheaper each effective token becomes — and you gain predictable throughput that doesn't compete with on-demand quota limits during peaks.
It is the wrong tool for spiky, exploratory, or low-volume workloads, where you would pay for idle hours that on-demand would have billed at zero. A common enterprise pattern is hybrid: provisioned capacity sized to the steady base load, with overflow traffic spilling to on-demand and handled by ordinary retry logic. If your real problem is occasional throttling rather than sustained volume, a quota increase is usually the cheaper first move. And before committing spend, compare the alternatives for non-urgent work: Bedrock's own S3-based batch inference offers select models at 50% below on-demand pricing — though note batch inference is not supported for provisioned models.
Sizing a commitment
Because an MU is defined in input-TPM and output-TPM terms, sizing starts from the same numbers as quota planning: average tokens per request (input and output separately — the ratio matters here), requests per minute at base load, and peak-to-base ratio. Size MUs to the base, not the peak; buying reserved capacity for a peak that occurs one hour a day is how provisioned deals go over budget. Start with the shortest commitment that gets an acceptable rate, validate utilization against real traffic, then extend the term once the base load is proven.
Attaching it to requests and other constraints
When you create a Provisioned Throughput, it becomes an account resource with its own ARN, in the form arn:aws:bedrock:{region}:{account-id}:provisioned-model/{name}. You direct traffic at it by referencing the provisioned model in your invocations in place of the on-demand model identifier, and IAM policies can scope bedrock:InvokeModel to that ARN so only the intended workload consumes the capacity you're paying for. Check the Provisioned Throughput documentation for the exact invocation details in your SDK.
Three boundaries matter for architecture:
It's regional and runtime-only. Provisioned Throughput applies to the bedrock-runtime endpoint (the legacy InvokeModel/Converse surface), not to the bedrock-mantle endpoint that serves the current "Claude in Amazon Bedrock" surface.
It doesn't ride inference profiles. Cross-region inference profiles do not support Provisioned Throughput, so your reserved capacity cannot participate in multi-region routing — plan failover for provisioned workloads separately (see the failover guide).
No batch. Bedrock's batch inference does not run against provisioned models.
Where to go next
Ground the sizing numbers in Bedrock quota dimensions, and see capacity planning for the broader forecasting method.