Amazon Bedrock is AWS's managed service for foundation models, and for many AWS-committed enterprises it is the sanctioned door to Claude. The good news for your developers: the official Python SDK — the same anthropic package they already use — includes Bedrock client classes, so switching platforms does not mean rewriting the application. This article covers what changes, what stays identical, and one naming subtlety that trips people up.
Two Bedrock surfaces, two client classes
Bedrock exposes Claude through two API surfaces, and the Python SDK has a client for each. The current surface — "Claude in Amazon Bedrock," which speaks the native Messages API — is served by AnthropicBedrockMantle. The legacy surface, Bedrock's own InvokeModel/Converse APIs, is served by the older AnthropicBedrock class and uses ARN-versioned model IDs such as global.anthropic.claude-opus-4-6-v1. New work should default to the current surface; treat AnthropicBedrock as the compatibility path for existing integrations. (When people say "switching to AnthropicBedrock" loosely, they usually mean the family — check which surface your code actually targets.)
What changes from Anthropic()
Three things: installation extras, authentication, and model IDs.
# pip install -U "anthropic[bedrock]"
from anthropic import AnthropicBedrockMantle
client = AnthropicBedrockMantle(aws_region="us-east-1")
message = client.messages.create(
model="anthropic.claude-sonnet-5",
max_tokens=1024,
messages=[{"role": "user", "content": "Hello, Claude"}],
)
Authentication is AWS, not Anthropic. There is no api_key parameter and no ANTHROPIC_API_KEY. The client authenticates with your standard AWS credentials — the same credential chain (environment variables, shared config, instance roles) every other AWS SDK call in your estate uses. Access is therefore governed by IAM, which is precisely why security teams like Bedrock: Claude access becomes a policy decision, not a new secret to manage.
Region is explicit. You pass aws_region and your requests go to Bedrock in that region (the legacy AnthropicBedrock class falls back to us-east-1 if none is set — an easy way to accidentally send traffic to the wrong region, so set it explicitly). Note that on Bedrock, regional and multi-region endpoints carry a 10% price premium over global endpoints for Claude Sonnet 4.5, Haiku 4.5, Opus 4.5, and all later models.
Model IDs gain a prefix. Bedrock is the only platform that prefixes model IDs with anthropic. — so claude-sonnet-5 becomes anthropic.claude-sonnet-5, and likewise anthropic.claude-opus-4-8 and anthropic.claude-fable-5. Older models are date-versioned: Haiku 4.5 is anthropic.claude-haiku-4-5-20251001-v1:0. See why model IDs differ across platforms for the full picture.
What stays identical
The part your application actually depends on: client.messages.create(...) keeps the same shape — same model/max_tokens/messages parameters, same structured response object. The core capabilities are all present on Bedrock: streaming, tool use, vision, extended and adaptive thinking, and prompt caching (5-minute and 1-hour). That is what makes multi-platform code realistic: business logic written against the Messages API does not care which door the request went through.
anthropic-beta header, so beta features cannot be switched on. AWS does offer its own S3-based batch inference for Claude — a different mechanism from Anthropic's Batches API, not an absence of batch options. Details in the feature gaps article.Across languages
The clean client-class story above is specifically the Python SDK. The official TypeScript, Java, Go, Ruby, C#, and PHP SDK READMEs do not document Bedrock client classes, so for other languages, use AWS's own SDKs against Bedrock (see boto3 setup, the JavaScript path, and the Java path) or check current official documentation. The concepts — AWS credential chain, explicit region, prefixed model IDs, identical request shape — transfer regardless of language.
Where to go next
Walk through your first Claude call on Bedrock end to end, including console-side model access. Then review Converse vs InvokeModel if you have legacy-surface code, and the feature matrix before finalizing platform choice.