Deploying Claude on Amazon Bedrock: IAM, Provisioning, and Cross-Region Inference

Amazon Bedrock puts Claude behind your existing AWS account: IAM controls who can call it, model access is requested per model per region, and some models need a cross-region inference profile to handle capacity and latency.

Summary

Bedrock is not a drop-in replacement for the direct Anthropic API - it is a different authentication and provisioning model layered on the same underlying Claude models.

Before any application code can call Claude on Bedrock, three things must exist: an IAM principal with permission to invoke Bedrock, an explicit grant of access to the specific model you want, and, for some models, a cross-region inference profile rather than a plain single-region model ID.

Skipping any one of those three steps produces a permission or not-found error that looks like a code bug but is actually a provisioning gap.

This page walks through IAM setup, requesting model access, and choosing between a plain model ID and a cross-region inference profile, then shows the request shape your application code actually calls.

Recipe

Quick-reference recipe card - copy-paste ready.

from anthropic import AnthropicBedrock
 
client = AnthropicBedrock(aws_region="us-east-1")
 
response = client.messages.create(
    model="anthropic.claude-sonnet-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Summarize this ticket in one sentence."}],
)
print(response.content[0].text)

When to reach for this:

• Your organization already runs production workloads on AWS and wants Claude usage to flow through existing IAM and billing.
• You need Claude's traffic to stay inside an AWS-managed network boundary for compliance reasons.
• You want Claude spend to count against an existing AWS Enterprise Discount Program or committed-use agreement.
• You are integrating Claude into an application that already assumes an IAM role for every other AWS service call.

Working Example

import os
from anthropic import AnthropicBedrock
import anthropic
 
# aws_region is required - there is no default region fallback for Bedrock.
client = AnthropicBedrock(aws_region=os.environ.get("AWS_REGION", "us-east-1"))
 
 
def summarize_ticket(ticket_text: str) -> str:
    """Call Claude on Bedrock and return a one-sentence summary.
 
    Assumes the caller's IAM role has bedrock:InvokeModel permission and
    that model access for claude-sonnet-5 has been granted in this region.
    """
    try:
        response = client.messages.create(
            model="anthropic.claude-sonnet-5",
            max_tokens=200,
            messages=[
                {
                    "role": "user",
                    "content": f"Summarize this support ticket in one sentence:\n\n{ticket_text}",
                }
            ],
        )
        return response.content[0].text
    except anthropic.PermissionDeniedError:
        raise RuntimeError(
            "IAM role lacks bedrock:InvokeModel, or model access was never "
            "granted for this model in this region."
        )
    except anthropic.NotFoundError:
        raise RuntimeError(
            "Model ID not found - check the anthropic. prefix and confirm "
            "the model is available in this AWS region."
        )
 
 
if __name__ == "__main__":
    ticket = "Customer reports login page returns a 500 error after the latest deploy."
    print(summarize_ticket(ticket))

What this demonstrates:

• AnthropicBedrock resolves AWS credentials through the standard chain (environment variables, shared credentials file, or an assumed IAM role) - there is no separate Anthropic API key involved.
• The anthropic. prefix on the model ID is mandatory on Bedrock; the bare claude-sonnet-5 ID from the direct API returns a 404 here.
• Catching PermissionDeniedError and NotFoundError separately turns the two most common first-deploy failures into an actionable message instead of a stack trace.

Deep Dive

How It Works

• Every Bedrock request is authenticated as an AWS IAM principal (a role or user), not by an Anthropic-issued API key - the SDK signs requests using the AWS credential chain, the same way any other boto3-backed call would.
• The IAM principal needs an attached policy granting bedrock:InvokeModel (and bedrock:InvokeModelWithResponseStream for streaming) scoped to the specific model ARNs you intend to call.
• Having the IAM permission is necessary but not sufficient - each model also requires an explicit model access grant, requested per model per AWS region in the Bedrock console before the first successful invocation.
• Model access requests are typically approved automatically for most Claude models, but the grant is still a separate step from IAM policy attachment, and both must be in place before traffic flows.
• Some models additionally require a cross-region inference profile instead of a plain model ID - a profile ID that lets Bedrock route a single logical request across multiple regions within a geography for extra capacity and lower queueing latency during demand spikes.

IAM Policy Shape

A minimal IAM policy for invoking Claude on Bedrock scopes the action to the specific model resources rather than granting blanket Bedrock access:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-5",
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-opus-4-8"
      ]
    }
  ]
}

• Scoping Resource to exact model ARNs, rather than "*", means adding a new model later requires a deliberate policy update rather than being silently already-allowed.
• If you use a cross-region inference profile, the resource ARN pattern changes to reference the inference profile rather than the plain foundation-model ARN - check the Bedrock console for the exact ARN once the profile is provisioned.

Model IDs vs. Cross-Region Inference Profiles

• The profile ID's geography prefix (us., for example) indicates which set of regions the profile is allowed to route across - it does not mean the request always leaves your primary region, only that it may during high demand.
• Using a profile ID where a plain model ID would work is harmless; using a plain model ID where a profile is required returns a ValidationException at request time, not a silent fallback.

Python Notes

from anthropic import AnthropicBedrock
 
# Prefer environment-driven region configuration over a hardcoded string,
# so the same code deploys cleanly to a second region later.
client = AnthropicBedrock(aws_region="us-east-1")
 
# Streaming works identically to the direct API - only the client class differs.
with client.messages.stream(
    model="anthropic.claude-sonnet-5",
    max_tokens=512,
    messages=[{"role": "user", "content": "Draft a short release note."}],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

• AnthropicBedrock exposes the same messages.create and messages.stream methods as the direct-API client - code written against the direct API needs only a client-construction change to run on Bedrock.
• The legacy AnthropicBedrock client uses the bedrock-runtime InvokeModel path; check current SDK documentation for the newer Mantle-based client if you need the latest Messages API surface on Bedrock.

Parameters & Return Values

Gotchas

• Forgetting the anthropic. prefix on the model ID. A bare claude-sonnet-5 string that works on the direct API returns a 404 on Bedrock. Fix: always prefix Bedrock model IDs with anthropic..
• IAM policy attached but model access never requested. The role has bedrock:InvokeModel, but the account never requested access to that specific model in the Bedrock console. Fix: check the Bedrock console's Model Access page for that model and region before assuming it's an IAM problem.
• Region mismatch between IAM policy and client construction. The IAM policy scopes the model ARN to us-east-1, but AnthropicBedrock(aws_region="us-west-2") is used at runtime. Fix: keep the IAM policy's resource ARNs and the client's aws_region in sync, or scope the policy to multiple regions deliberately.
• Using a plain model ID where a cross-region inference profile is required. Some models reject a plain anthropic. model ID with a validation error. Fix: check the Bedrock console for whether the model requires an inference profile ID before wiring up the integration.
• Assuming model access approval is instant. Some models or regions can have a review delay before access is granted. Fix: request model access well before a launch date, not on the day of deployment.
• Hardcoding a single region with no fallback plan. A regional Bedrock outage or capacity limit then has no mitigation. Fix: consider a cross-region inference profile, or a fallback path to another platform, for latency- or availability-sensitive workloads.

Alternatives

FAQs

Related

• Choosing Between Direct API, Bedrock, and Vertex AI for Claude - decide whether Bedrock is the right platform before provisioning it.
• Enterprise Deployment Basics - the minimal first call across all three platforms, including Bedrock.
• Running Claude on Google Cloud Vertex AI: Quotas and Service Accounts - the equivalent provisioning steps on GCP.
• Data Residency and Region-Pinning Checklist for Regulated Workloads - how region choice on Bedrock interacts with compliance requirements.
• Comparing Bedrock, Vertex AI, and Direct Anthropic API Access - trade-offs across all three platforms in one table.

Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5 - and the official anthropic Python SDK (latest 0.x release). Model names, pricing, and SDK versions move quickly - verify current specifics at platform.claude.com/docs before relying on them.