A ThrottlingException (HTTP 429) on Amazon Bedrock means your account has exceeded a quota. For Claude, Bedrock mainly counts tokens per minute, per model and region, input and output combined, plus a daily limit across all models. The most common reason for throttling under light load: at the start of every request Bedrock reserves the input plus the full max_tokens value, and output tokens count ten times for models such as Opus 5.5. The fixes, in this order: retry with exponential backoff and jitter, set max_tokens to a realistic value, check your quota in Service Quotas and request an increase if needed. Sources as of 1 November 2026, not from a load test of my own.
I use Bedrock in production myself in some cases and have set it up for clients, wherever processing in the EU is required; my own workforce runs on Claude with a DPA day to day. Regions, the EU profile and data paths are explained in Claude on AWS Bedrock: EU, GDPR and Cost; this article is about why Bedrock throttles and what you can do about it.
Which Bedrock quotas apply to Claude
On the standard bedrock-runtime endpoint, these quotas apply per model, shared across InvokeModel, Converse and the other APIs, according to AWS:
The default values in AWS's reference table on 1 November 2026: Opus 5.5 gets 30 million tokens per minute for both cross-region and global, Sonnet 5.5 gets 6 million and Haiku 5.5 10 million. The daily limit is 700 million tokens and is marked as not adjustable in the table. The table lists no requests-per-minute quota for the 5.5 models. AWS adds two caveats itself: your account's values may be lower, depending on region, account age, usage and payment history, and only the Service Quotas console shows what applies to you. And the second endpoint, bedrock-mantle, has its own quotas, split into input and output.
One point matters for Europe: Sonnet 5.5 and Haiku 5.5 aren't available there as a single region, and Opus 5.5 only in London. If you work through the EU profile, the cross-region quota is the one you hit.
Why Bedrock throttles even under light load
AWS describes the counting like this:
- At the start Bedrock deducts input tokens plus
max_tokens from the per-minute and daily quotas. If the quota isn't sufficient, the request is throttled.
- During the response Bedrock adjusts to the tokens actually generated.
- At the end input tokens plus cache writes plus output tokens times a factor count. Cache reads don't count, and the rest is returned to your quota.
AWS calls the factor the burndown rate: 10 for Opus 5.5, Sonnet 5, Opus 5 and Fable 5.1, 15 for the version 4.8 models, 5 for version 4.7 and older. For Sonnet 5.5 and Haiku 5.5 the page gives no value of its own as of 1 November 2026. You're billed only for actual usage; the factor affects only the quota.
AWS works through an example with a factor of 5: 3,000 input tokens, 1,000 written to the cache, 1,000 output tokens. With max_tokens at 32,000, the request reserves 36,000 tokens at the start but ends up using only 9,000. With max_tokens at 1,250, it reserves 5,250. An oversized max_tokens therefore blocks quota you never use and reduces how many requests can run at once. AWS's advice: set max_tokens close to the real response length and read the numbers for that from CloudWatch.
ThrottlingException and the other errors
The distinction saves time: a higher quota helps with a ThrottlingException, not with 503 or 529. For both capacity errors, AWS recommends retrying with backoff and cross-region inference; for 503 also another region.
Retrying with backoff and jitter
The AWS SDKs retry throttled requests on their own. How exactly currently depends on a switch: AWS describes the new 2026 behaviour, which you opt into with AWS_NEW_RETRIES_2026=true until it becomes the default; without it, AWS says backoff timing and defaults differ. In the new standard mode the SDK waits exponentially longer, with a random component (jitter) so that clients don't all come back at the same time. For throttling errors the base delay is one second, no single wait exceeds 20 seconds, and there are three attempts in total. You configure this with AWS_RETRY_MODE and AWS_MAX_ATTEMPTS, or retry_mode and max_attempts in ~/.aws/config. AWS recommends adaptive mode only when a client sends a lot to a single resource and gets throttled often; it then slows down the first request too.
Retrying only moves the problem. If CloudWatch shows you're permanently at the quota, what helps is lower usage or a higher quota.
Cross-region inference, global and the EU profile
A geographic profile such as eu.anthropic.claude-sonnet-5-5 spreads requests across several regions within the EU, a global profile across all commercial regions worldwide, with about 10 percent savings according to AWS. Each profile type counts against its own quota. If you need EU processing, stay with the EU profile; the global profile is not a fallback route then. Inference profiles don't support Provisioned Throughput. According to their model cards, Opus 5.5, Sonnet 5.5 and Haiku 5.5 support only the Standard service tier as of 1 November 2026, not Priority, Flex or Reserved.
Requesting a quota increase
- Open the Service Quotas console, then "AWS services" and "Amazon Bedrock".
- Search for the model, for example "Sonnet 5.5", and check your account's current value.
- Select the cross-region tokens-per-minute quota and request an increase.
AWS notes that increases aren't granted automatically. If you request the cross-region quota, support offers to raise the on-demand and daily quotas along with it. Accounts that actually use up their existing quota get priority; otherwise the request may be denied. Models in Legacy or Deprecated status get no increase. For quotas that support it, you can create a CloudWatch alarm in the same console that warns you before you hit the limit.
Token caps as a cost brake
Bedrock quotas apply per account and region, not per person. Claude Desktop in Bedrock mode has a per-person cap: inferenceMaxTokensPerWindow with inferenceTokenWindowHours. Cached tokens don't count, so according to Anthropic the cap doesn't limit your bill. How to set it is covered in Set Up Claude Desktop with Amazon Bedrock. For budget alerts and cost per department, see AWS Bedrock Pricing: Claude Costs and Budgets.
Claude Code on Bedrock: the settings
On Bedrock, Claude Code uses the Invoke API, not Converse, and counts against the same quotas. According to the docs:
CLAUDE_CODE_USE_BEDROCK=1 and AWS_REGION, for Frankfurt eu-central-1. In EU regions Claude Code uses the eu. prefix; ANTHROPIC_BEDROCK_REGION_PREFIX changes the default.- Set
ANTHROPIC_MODEL. Without it, according to the docs, you're billed at the Opus rate.
CLAUDE_CODE_MAX_RETRIES sets the number of retries, default 10.CLAUDE_CODE_RETRY_WATCHDOG=1 retries 429 and 529 errors indefinitely, meant for unattended runs; CLAUDE_CODE_RETRY_WATCHDOG_MAX_WAIT_MS limits the waiting time.CLAUDE_CODE_MAX_OUTPUT_TOKENS sets the upper limit for output tokens on most requests.
The last variable is my inference from the two sets of docs, not a measured effect: because Bedrock reserves max_tokens at the start, a smaller value lowers the reservation per request. Don't set it too low: according to the docs, Claude Code cuts off a reply that hits the limit, and a fixed thinking budget has to stay below the value. Lower it step by step and go by the real response lengths in CloudWatch. If Claude Code reports "on-demand throughput isn't supported", enter an inference profile instead of the model ID. Installation itself is covered in Install Claude Code: Windows, Mac, Linux.
Monitoring with CloudWatch
Bedrock writes metrics to the AWS/Bedrock namespace:
InvocationThrottles: throttled calls. How many you see depends on your SDK retry settings, according to AWS.InvocationClientErrors: client errors, which according to AWS include requests rejected for exceeding a service quota; those don't count as throttles.InputTokenCount, OutputTokenCount, CacheWriteInputTokenCount, CacheReadInputTokenCount: usage.EstimatedTPMQuotaUsage: estimated quota usage. AWS warns that throttling is based on the reservation and that this estimate shouldn't be your only basis.
Two notes from the docs: errors that occur before the model is identified are missing from the per-ModelId view, so query without a dimension for totals. And under "Dashboards → Automatic dashboards → Bedrock", "Token Counts by Model" shows usage per model. Which region served a request is in CloudTrail in the field additionalEventData.inferenceRegion.
Frequently asked questions
What does ThrottlingException mean on Bedrock?
Your account has exceeded a quota for the model, usually tokens per minute. The request was rejected and can be retried; backoff with jitter is the first step.
Why am I throttled even though I use few tokens?
Because Bedrock reserves input plus max_tokens at the start and counts output tokens ten times over for models such as Opus 5.5. A large max_tokens blocks quota even if the response stays short.
Does the global profile help against throttling?
It has its own quota and spreads requests across more regions. But requests may then be processed outside the EU. For EU requirements it is not a solution.
Are throttled requests billed?
AWS bills by actual token usage, not by the reservation against the quota. Throttled requests also don't appear in the Invocations metric, which counts accepted requests.
Where to go from here
First check your account's real values in Service Quotas, then InvocationThrottles and token usage over the last few days in CloudWatch. If your peak is close to the quota, request the increase; if it's far below, max_tokens is usually too large. Everything else about Claude is collected on my Claude page, and you can bring questions to my community.
Your first AI employee up and running within an hour
Join the community$5/month founding price, first 50 members
