Bedrock surfaces failures as typed exceptions with an HTTP status code, and the exception name usually points at whose problem it is: AccessDeniedException means permissions or entitlement, ValidationException means your request body, ThrottlingException means quota, and ModelNotReadyException means the model isn't invocable yet. Here is the diagnosis order for each.
AccessDeniedException
This is the classic day-one error, and it has three distinct causes worth checking in sequence.
Marketplace entitlement. Access to Bedrock foundation models is enabled by default given correct AWS Marketplace permissions, and the first invocation of a third-party model auto-initiates the Marketplace subscription — but if the prerequisites are missing, you get AccessDeniedException. The identity enabling a model for the first time needs aws-marketplace:Subscribe, aws-marketplace:Unsubscribe, and aws-marketplace:ViewSubscriptions; these are only needed once per model per account.
The Anthropic use-case form. On the classic bedrock-runtime surface, Anthropic models require a one-time First Time Use form per account or AWS Organization (a management-account submission is inherited by member accounts), submitted via the console or the PutUseCaseForModelAccess API. This requirement does not apply to Anthropic models on the newer bedrock-mantle endpoint.
Plain IAM. The calling identity needs the inference actions on the right resources: bedrock:InvokeModel / bedrock:InvokeModelWithResponseStream (or the Converse actions) on the foundation-model ARN — and, when calling through a cross-region inference profile, on both the foundation-model/* and inference-profile/* ARNs. Forgetting the inference-profile ARN is the most common miss. On the mantle surface the action namespace differs: bedrock-mantle:CreateInference. Also check for organization-level service control policies: geographic inference profiles need all destination regions allowed, and global profiles need "aws:RequestedRegion": "unspecified" permitted.
ValidationException
Bedrock rejected the request body. Frequent causes for Claude specifically:
| Cause | Fix |
|---|---|
Missing anthropic_version on InvokeModel | Include "anthropic_version": "bedrock-2023-05-31" alongside max_tokens and messages |
| Prompt too long | Input exceeds the model's context window (1M tokens on recent models, 200K on Sonnet 4.5 and older); trim or chunk |
| Payload too large | Bedrock caps request payloads at 20 MB — relevant with base64 documents and images |
| Model-generation mismatch | Manual extended thinking, assistant prefill, or non-default temperature/top_p/top_k on Opus 4.7+/Sonnet 5 return 400 — these newer models use adaptive thinking and reject those parameters |
| Malformed message structure | Messages must alternate user/assistant roles with correctly typed content blocks |
ThrottlingException
You exceeded a quota. Bedrock meters Claude primarily in tokens per minute, and the two endpoints keep separate books: bedrock-runtime has per-model TPM quotas (input and output counted together), requests-per-minute quotas for some models, and tokens-per-day quotas; bedrock-mantle has separate input-TPM and output-TPM quotas per model and no RPM quotas. Mantle also uses admission control — your input tokens plus max_tokens are reserved against the input quota when the request is admitted, and oversized reservations return a 429 even if actual generation would have fit. Cached input tokens read via prompt caching do not count against the mantle input-TPM quota.
Remediation, in order: implement exponential backoff with jitter and retry (throttling is often transient at traffic peaks); reduce demand per request (tighter max_tokens directly shrinks mantle reservations; prompt caching removes cached tokens from the metered count); smooth bursts through a queue; and finally raise the quota — adjustable bedrock-runtime quotas go through the Service Quotas console, while bedrock-mantle increases require an AWS Support case specifying endpoint, region, model, and quota name. Note that increases are not granted for models in Legacy or Deprecated lifecycle status.
ModelNotReadyException
The model cannot serve your request yet. AWS's error documentation is the authority on exact semantics, but the pattern operators see is around first use in an account: enabling a third-party model kicks off a Marketplace subscription that can take up to 15 minutes to complete, and invocations during provisioning fail. The remediation is unexciting — wait briefly and retry with backoff; if it persists well beyond that window, verify the model is available in your region (Anthropic model availability varies by AWS region) and open a support case.
request-id of the failed responses — the documented support contact is bedrock-ant-eap@amazon.com.Where to go next
Throttling handling and quota increase requests go deeper on the 429 path; IAM setup for Bedrock prevents the access errors in the first place; and retries and fallbacks covers resilience patterns generally.
Sources
- Access Amazon Bedrock foundation models (AWS documentation)
- Identity-based policy examples for Amazon Bedrock (AWS documentation)
- Quotas for the bedrock-mantle endpoint (AWS documentation)
- Anthropic Claude Messages API on Bedrock (AWS documentation)
- Claude in Amazon Bedrock (Anthropic documentation)