Quotas are the ceilings AWS places on how fast an account can consume a service. For Claude on Bedrock they come in a handful of dimensions, and the first thing to understand is that Bedrock has two inference endpoints with separate quota books: bedrock-runtime (the legacy InvokeModel/Converse surface) and bedrock-mantle (the current "Claude in Amazon Bedrock" surface). Traffic to one endpoint is tracked against that endpoint's quotas even when both serve the same model — moving workloads between surfaces means re-checking your headroom.
The dimensions on bedrock-runtime
The legacy endpoint enforces per-model quotas under names you can look up directly:
| Quota | What it limits |
|---|---|
| InvokeModel requests per minute (RPM) | How many calls per minute, regardless of size |
| On-demand InvokeModel tokens per minute (TPM) | Input + output tokens combined, per minute |
| Cross-Region InvokeModel tokens per minute | The TPM pool for traffic routed via inference profiles |
| Model invocation max tokens per day | A daily cap, defaulting to the per-minute quota × 24 × 60 |
Two details are easy to miss. First, runtime TPM counts input and output tokens together against one per-model number — a chatty model eats the same budget as a wordy prompt. Second, RPM quotas are model-specific and not universal: Claude Opus 4.7 and Opus 4.8, for example, have no RPM quota at all and are governed solely by token quotas. Don't assume the constraint mix for one model carries over to another.
The dimensions on bedrock-mantle
The current surface uses a different model: "Bedrock Mantle input tokens per minute" and "Bedrock Mantle output tokens per minute" are tracked separately per model, and no RPM quotas are enforced on this endpoint at all. Two behaviors follow from its admission-control design:
Your max_tokens is reserved up front. When a request arrives, Bedrock reserves your input tokens plus your requested max_tokens (or the model maximum if unset) against the input-TPM quota, returning an HTTP 429 if that would exceed it. Unused reservation is replenished after the request completes. Practical consequence: habitually setting a huge max_tokens "just in case" reduces how many requests can be admitted per minute, even if actual outputs are short.
Cache reads are free against the quota. Cached input tokens read via prompt caching do not count against the mantle input-TPM quota — so prompt caching is a throughput lever, not just a cost lever, on this endpoint.
On published numbers, sources currently diverge: AWS's mantle quota table lists Claude Opus 4.7 at a 20,000,000 input TPM / 4,000,000 output TPM default (other Claude models have no published per-account figures yet), while Anthropic's documentation states a default of 2 million input TPM for Claude in Amazon Bedrock, expandable to 4 million without additional Anthropic approval. The discrepancy is unresolved in the official pages; treat the Service Quotas console for your own account as ground truth.
What about concurrency?
Bedrock's published per-model dimensions for Claude are request-rate and token-rate quotas rather than an explicit concurrent-connections number for standard invocations. In practice, concurrency is constrained indirectly — mantle's reservation of max_tokens per in-flight request means many simultaneous long-generation requests exhaust input TPM quickly. If your workload is dominated by long streaming responses, model your limit as "in-flight reservations per minute," not "requests per second." Check the Service Quotas console for any additional adjustable quotas that apply to your account.
Which dimension bites first
For most production Claude workloads, tokens per minute is the binding constraint, for a simple reason: enterprise use cases lean on long context — retrieved documents, conversation history, tool definitions — so each request carries thousands to hundreds of thousands of tokens. A modest 60-requests-per-minute workload at 50k tokens each is 3M TPM. RPM tends to bind only for high-frequency, short-prompt patterns like classification at scale, and on models that have an RPM quota at all. The daily token cap matters for batchy traffic: a spiky workload can stay under TPM every minute and still exhaust the day's budget.
Where to go next
When the math says you'll hit a ceiling, request an increase before launch, and implement proper retry handling for the throttles you'll still occasionally see. Sustained baselines may justify Provisioned Throughput.