Claude Platform on AWS is Anthropic-operated: the same company runs the models, but AWS provides the authentication layer, IAM-based access control, and billing through AWS Marketplace. It exposes the Claude API surface directly (/v1/{endpoint}), with typically same-day feature parity with the first-party API. That makes this the gentlest of the 3P migrations — most of your code, prompts, and evaluation baselines carry over untouched.
What changes
The client class. Swap Anthropic() for AnthropicAWS() (from the same anthropic package, installed with pip install -U "anthropic[aws]"). Method calls are identical.
from anthropic import AnthropicAWS
# Before: Anthropic() + ANTHROPIC_API_KEY
# After: AWS credentials + two env vars:
# export AWS_REGION='us-west-2'
# export ANTHROPIC_AWS_WORKSPACE_ID='wrkspc_01AbCdEf23GhIj'
client = AnthropicAWS()
msg = client.messages.create(
model="claude-opus-4-8",
max_tokens=256,
messages=[{"role": "user", "content": "Hello"}],
)
Authentication. Instead of a long-lived sk-ant-api... key in the x-api-key header, requests are SigV4-signed with your AWS credentials (service name aws-external-anthropic), resolved through the standard AWS provider chain — env vars, shared config, SSO, IRSA, ECS, EC2 instance metadata. Your first-party API keys do not work on this endpoint. API-key auth does exist here as an alternative, but those keys are generated in the AWS Console, and OAuth authentication is not supported at all.
Workspace ID. Every request carries an anthropic-workspace-id header; the SDK sets it from ANTHROPIC_AWS_WORKSPACE_ID or the workspace_id constructor argument. Both the region and workspace ID are required with no default: the constructor raises immediately if either is missing. Workspaces are bound to a single AWS region, so AWS_REGION must match where the workspace was created.
A new organization. Signing up provisions a fresh Anthropic organization tied to your AWS account. API keys, workspaces, and Console settings from your existing first-party org do not carry over — plan to recreate workspaces and re-upload workspace-scoped resources like Files and Skills. One one-time prerequisite: enable outbound web identity federation (aws iam enable-outbound-web-identity-federation), or every request fails with a federation-disabled error.
Billing and limits. Billing moves to AWS Marketplace, denominated in Claude Consumption Units (CCUs) at $0.01 per CCU, metered hourly and invoiced monthly in arrears. Rate limits are still managed by Anthropic — new organizations start on the Start tier and do not move up automatically; contact Anthropic to raise limits. Console spend limits are not available; use AWS billing controls instead.
What stays identical
Model IDs are the bare first-party strings (claude-opus-4-8, claude-sonnet-5, claude-haiku-4-5...), with identical context windows. The request and response format, SSE streaming, the anthropic-version: 2023-06-01 header, and anthropic-beta passthrough for beta features all match the first-party API. Feature-wise you keep prompt caching (all variants), tool use including computer use, extended thinking, Message Batches, the Files API, code execution, web tools, Agent Skills, and Managed Agents. New models launch simultaneously with the first-party API. Data handling follows the same retention policy as the first-party Claude API, with Zero Data Retention available on request through an Anthropic account representative.
The documented exceptions
"Same-day parity" is the norm, not an absolute. Things that do not exist on Claude Platform on AWS: most Admin API endpoints (only the workspace endpoints are available — members, invites, API keys, and usage/cost reports are managed through AWS and IAM instead), the programmatic Usage and Cost API, Console spend limits, Anthropic's HIPAA-ready program, OAuth auth, fast mode, OpenAI-compatible endpoints, and MCP tunnels (public MCP servers only). If your operations depend on any of these — usage-report pipelines are the common one — solve that before cutover, for example with CloudTrail plus AWS billing data.
A short verification list
Confirm: the two env vars are set in every deployment environment; principals carry the needed aws-external-anthropic IAM actions (a 403 means the request arrived but the workspace ID or IAM policy is wrong); streaming and caching behave as before; and your logs capture both response request IDs (x-amzn-requestid and request-id) for support escalations on either side.
Where to go next
Start with subscribing via AWS Marketplace and your first API call, then wire up IAM policies.