This article was co-authored by Manojit Saha Sardar (manojits@), a Senior Cloud Support Database Engineer at AWS specializing in AWS DMS, Amazon RDS, and Aurora PostgreSQL, with 7 years in high-impact database escalations and migration troubleshooting.

As organizations move generative AI applications from prototype to production, one of the most critical — and often overlooked — operational concerns is capacity management. Amazon Bedrock provides powerful foundation models through a simple API, but understanding how quotas work, how to monitor utilization, and how to plan for growth can mean the difference between a smooth launch and unexpected throttling at peak traffic.

This post shares practical guidance for engineering and platform teams managing Bedrock quotas across multiple accounts, environments, and models.

Amazon Bedrock uses a layered capacity system. Understanding each layer helps you plan appropriately:

Every AWS account has default quotas for each model:

·       Tokens Per Minute (TPM) — the maximum tokens processed per minute (input + output combined, with burndown rates applied)

·       Requests Per Minute (RPM) — the maximum number of API calls per minute

These are enforced per-account, per-model, per-region. You can request increases through the AWS Service Quotas console.

Cross-Region Inference routes requests across multiple regions automatically. This provides:

·       2x burst capacity at no additional cost

·       Automatic failover if one region is constrained

·       Same pricing as single-region inference

Recommendation: Always use Global CRIS (global. prefix) for production workloads unless you have data residency requirements. It's the single easiest way to reduce throttling risk.

For workloads requiring guaranteed throughput, the Reserved Tier provides dedicated capacity:

·       Guaranteed input TPM, output TPM, and RPM

·       Accessed by passing serviceTier: { type: "reserved" } in API calls

·       Separate from on-demand quotas — they don't share limits

·       1 or 3 month commitment

Key point: Reserved Tier capacity exists alongside your on-demand quota. You need to explicitly opt in per request. Without the serviceTier parameter, all traffic goes to on-demand.

For models on the bedrock-runtime endpoint, output tokens consume quota at a higher rate than input tokens. The burndown rate varies by model family.

Note: Token burndown rates apply only to models on the bedrock-runtime endpoint. Models available exclusively on the bedrock-mantle endpoint have separate input and output TPM quotas, so burndown does not apply.

Quota consumed = Input Tokens + Cache Write Tokens + (Output Tokens × burndown rate)

Cache read tokens don't count toward on-demand quota.

This means a request with 10,000 input tokens and 500 output tokens and 15x burn down rate doesn't consume 10,500 tokens of quota — it consumes 17,500.
10,000 + (500 × 15) = 17,500.

This makes right-sizing max_tokens and monitoring EstimatedTPMQuotaUsage even more critical as you adopt newer model versions.

For models with large output (code generation, long-form content), this multiplier significantly reduces effective throughput. Monitor EstimatedTPMQuotaUsage in CloudWatch — it applies burndown rates automatically and gives you the true quota consumption.

Reference: How tokens are counted in Amazon Bedrock  Aug 28, 2026

This is the most commonly missed cause of unexpected throttling.

When you make a Bedrock API call, the system reserves quota upfront based on your max_tokens parameter:

Upfront reservation = Input Tokens + CacheWriteInputTokens + max_tokens

This reservation is deducted from your TPM quota before the model starts generating output. If the reservation would exceed your remaining quota, the request is throttled immediately.

After the response completes, the system adjusts the deduction to reflect actual usage:

The unused portion (the difference between the upfront reservation and the final consumption) is then replenished to your quota.

Why this matters: If you set max_tokens: 4096 but your model typically generates 200 tokens, you're reserving 4,096 tokens of quota per request upfront — even though final consumption will only be 200 x 5 = 1000 (for a 5x burndown model). During burst traffic, these large upfront reservations stack up across concurrent requests and trigger throttling even though your actual post-completion usage shows plenty of headroom.

The key insight: upfront reservation is 1:1 for max_tokens (no burndown applied), but it still blocks quota capacity until the request completes. With high concurrency and an oversized max_tokens, you exhaust your TPM budget in reservations alone.

Right-size max_tokens to your expected output length plus a reasonable buffer:

 

)

max_tokens is an output-length ceiling — a raw count of tokens the model may generate. Burndown is not applied to it. So a 512 means "up to 512 output tokens,". A 200-token response fits regardless of burndown.

  - Burndown applies only to quota accounting, not to the length limit. It never caps or changes how long your response can be.

For applications with variable output length, consider setting max_tokens based on the P95 of your actual output distribution rather than the model's maximum.

 

Source How tokens are counted in Amazon Bedrock  —

 

Most organizations run separate AWS accounts for development, QA, staging, and production. A common failure pattern:

1.     Development team gets quota increase on QA account during load testing

2.     Application passes all performance tests in QA

3.     Launch day: production account still has default quotas → immediate throttling

Maintain a matrix of quotas across environments:

When you increase quotas in QA for load testing, immediately request the same increases for Prod — don't wait until launch day.