A Bedrock ThrottlingException usually isn't about your total request volume the way it might be on another vendor — it's often about how quota is scoped and how much of it a single request reserves before it even runs. Here's what actually causes it and the real fixes.
Quota is shared across your entire account and region — not per deployment
Unlike Azure OpenAI, where tokens-per-minute and requests-per-minute quota is assigned per individual model deployment, Bedrock's RPM and TPM limits are scoped to your AWS account and region as a whole, shared across every application calling that model from that account and region. A separate, unrelated application in the same account and region draws from the exact same pool — so a throttling error can show up on a workload that, on its own, looks well within whatever limit you assumed it had.
Leaving max_tokens unset reserves the model's full output ceiling upfront
This is the least obvious cause: if you don't set max_tokens on a request, it defaults to the model's maximum — 64,000 for Claude Sonnet, for instance — and Bedrock reserves that much TPM quota upfront, before the model has generated a single output token, based on the assumption that it might use the full ceiling. A batch of concurrent requests that all leave max_tokens unset can exhaust your account's TPM quota through reservations alone, well before actual token generation would have. Setting an explicit, realistic max_tokens on every request is one of the most direct throttling fixes available and costs nothing to implement.
Claude models apply a token burndown multiplier to output tokens
For Claude models on Bedrock, output tokens don't count 1-for-1 against your TPM quota — a burndown rate multiplier (1x, 5x, or 15x depending on the specific model version) is applied when calculating how much quota a request actually consumes. A model version with a higher multiplier burns through the same TPM ceiling faster per output token than the raw token count would suggest, which matters when comparing throttling behavior across different Claude versions on Bedrock.
boto3's adaptive retry mode handles a lot of this automatically
Configuring the AWS SDK with adaptive retry mode — Config(retries={'mode': 'adaptive', 'max_attempts': 5}) in boto3 — adds built-in, token-bucket-based client-side rate limiting on top of standard retry-with-backoff, which smooths out bursty request patterns before they trigger a throttling response in the first place, rather than just retrying after one already happened.
Raising the ceiling for good
Quota increases go through the AWS Service Quotas console — current account defaults range from roughly 200K to 8M TPM depending on the specific model. For workloads that need dedicated, isolated capacity outside the shared account-level pool entirely, Provisioned Throughput is the equivalent of Azure's PTU or a similar reserved-capacity tier elsewhere. CloudWatch metrics — InvocationThrottles, InputTokenCount, OutputTokenCount — are the direct way to watch quota consumption over time rather than finding out about it from a failed request, and a circuit breaker in front of Bedrock calls is worth having for anything mission-critical.