Claude Platform on AWS in Practice

Migrating a Bedrock Application to Claude Platform on AWS

Both platforms run on AWS and both authenticate with IAM, so the migration is smaller than it sounds: four code-level changes, plus some account setup you should not discover in production.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Teams usually move from Amazon Bedrock to Claude Platform on AWS for feature reach: the Anthropic-operated platform gets typically same-day parity with the first-party Claude API — Message Batches, Files API, code execution, web tools, the anthropic-beta header — while Bedrock is an AWS-operated service with its own surface and schedule. Because both live behind AWS IAM, your credential story mostly carries over. Four things change in code.

Change 1: the client class

Bedrock's current Messages API surface uses AnthropicBedrockMantle; Claude Platform on AWS uses AnthropicAWS (install with pip install -U "anthropic[aws]"). Everything downstream of the constructor — client.messages.create(...) and friends — keeps the same shape.

from anthropic import AnthropicBedrockMantle, AnthropicAWS

# Before: Amazon Bedrock
client = AnthropicBedrockMantle(aws_region="us-east-1")
msg = client.messages.create(model="anthropic.claude-opus-4-8",
                             max_tokens=256,
                             messages=[{"role": "user", "content": "Hi"}])

# After: Claude Platform on AWS
client = AnthropicAWS()  # reads AWS_REGION + ANTHROPIC_AWS_WORKSPACE_ID
msg = client.messages.create(model="claude-opus-4-8",
                             max_tokens=256,
                             messages=[{"role": "user", "content": "Hi"}])

Change 2: auth and configuration

Both platforms sign requests with SigV4 through the standard AWS credential chain, so your roles and key management stay. What changes is the IAM vocabulary and the required configuration. Claude Platform on AWS signs for the service aws-external-anthropic, and your principals need its actions (for example CreateInference for POST /v1/messages) instead of Bedrock permissions — the AnthropicInferenceAccess managed policy is the narrowest managed option for inference. Every request must also carry a workspace ID: set ANTHROPIC_AWS_WORKSPACE_ID alongside AWS_REGION. Unlike AnthropicBedrock, which falls back to us-east-1, AnthropicAWS raises an error at construction if no region is set — a deliberately loud failure.

Two one-time account steps trip up most migrations: subscribe via the AWS Console's Claude Platform on AWS page (which provisions a new Anthropic organization tied to your AWS account), and enable outbound web identity federation with aws iam enable-outbound-web-identity-federation. Without the latter, every request fails with "Outbound web identity federation is disabled for your account" — the most common setup error.

Change 3: model ID format

Bedrock prefixes model IDs; Claude Platform on AWS uses the bare first-party IDs.

ModelBedrock IDClaude Platform on AWS ID
Claude Opus 4.8anthropic.claude-opus-4-8claude-opus-4-8
Claude Sonnet 5anthropic.claude-sonnet-5claude-sonnet-5
Claude Haiku 4.5anthropic.claude-haiku-4-5-20251001-v1:0claude-haiku-4-5

Keep model IDs in configuration, not code, and this becomes a config diff. Note that the platform follows Anthropic's first-party model deprecation lifecycle.

Change 4: the endpoint

Bedrock-Mantle exposes /anthropic/v1/messages; Claude Platform on AWS exposes the Claude API surface directly at https://aws-external-anthropic.{region}.api.aws/v1/.... The SDK builds this URL from your region, but anything that pins hostnames — VPC egress rules, proxy allowlists, WAF entries — needs updating. AWS PrivateLink is supported if you connect from a VPC. Remember the SigV4 region must match the endpoint region; a mismatch produces a generic signature-rejection error, not a helpful diagnostic.

Test checklist before cutover

Run these against the new platform with production-shaped traffic:

✔ A plain messages.create call succeeds per model you use, with bare IDs. ✔ Streaming works end to end (both use SSE on this surface, but verify your consumer). ✔ IAM: intended principals succeed and unintended ones get 403s. ✔ Prompt caching still reports cache hits in usage. ✔ Error handling: your retry logic treats the platform's 429/5xx responses correctly. ✔ Logging captures both response request IDs (x-amzn-requestid for AWS support, request-id for Anthropic). ✔ Billing appears via AWS Marketplace as Claude Consumption Units, and any Bedrock private offers are renegotiated — discounts do not transfer between the platforms and cannot be applied retroactively.

Worth knowing: Claude Platform on AWS uses a separate capacity pool from both the first-party API and Bedrock, so you can run both platforms in parallel during migration and fail over between them rather than doing a hard cutover.

One compliance caveat before you commit: organizations needing FedRAMP High, IL4/IL5, HIPAA-ready compliance, or AWS as sole data processor should stay on Claude in Amazon Bedrock — on Claude Platform on AWS, Anthropic is the data processor and inference may route to Anthropic's primary cloud.

Where to go next

Weigh the move itself with the Bedrock vs. Claude Platform decision guide, then set up the Python SDK and IAM policies.

Sources