Claude Platform on AWS exposes the same API surface as the first-party Claude API, so the Python setup will feel familiar if you have used the anthropic package before. The differences are all in authentication and configuration: requests are signed with AWS SigV4 (AWS's standard request-signing scheme) instead of an Anthropic API key, and every request must identify a workspace. The SDK's AnthropicAWS client handles the signing, the region-based endpoint URL, and the workspace header for you — once you give it the right inputs. Note that the platform-specific SDK clients for Claude Platform on AWS are currently in beta.
Install and configure
Install the package with the aws extra, which pulls in the AWS-specific dependencies:
pip install -U "anthropic[aws]"Then set the two values that have no default fallback:
export ANTHROPIC_AWS_WORKSPACE_ID='wrkspc_01AbCdEf23GhIj'
export AWS_REGION='us-west-2'The workspace ID is the tagged wrkspc_... identifier from the AWS Console (Claude Platform on AWS → Workspaces) or the Claude Console. The region must be the AWS region your workspace is bound to — workspaces are region-bound, so a us-west-2 workspace is only reachable through the us-west-2 endpoint. AWS_DEFAULT_REGION works as a fallback for the region; both values can also be passed as constructor arguments (workspace_id=, aws_region=). Unlike AnthropicBedrock, which quietly falls back to us-east-1, AnthropicAWS raises an error at construction if either value is missing — before any request is sent, which is the failure mode you want.
The right client class
Use AnthropicAWS — not AnthropicBedrockMantle, which targets Amazon Bedrock, a different service with different model ID formats. On Claude Platform on AWS, model IDs are the same bare strings as the first-party API (claude-sonnet-5, claude-opus-4-8), with no anthropic. prefix.
from anthropic import AnthropicAWS
client = AnthropicAWS() # reads env vars; raises here if they're missing
message = client.messages.create(
model="claude-sonnet-5",
max_tokens=100,
messages=[{"role": "user", "content": "Reply with exactly: setup verified"}],
)
print(message.content[0].text)If that prints a response, your install, configuration, credentials, and IAM permissions all work end to end. Use the client exactly as you would Anthropic() — client.messages.create(...), streaming, tool use, and the rest of the API surface behave the same way.
Because the platform exposes the first-party API surface with typically same-day feature parity, code you have already written against Anthropic() usually ports by swapping the client class: streaming uses the same server-sent events, beta features pass through with the standard anthropic-beta header, and context windows match the first-party API. Keep the model string in configuration rather than code, so switching between, say, claude-haiku-4-5 for cheap tests and claude-opus-4-8 for production is a deploy-time decision.
Where credentials come from
With no API key configured, the client signs requests using the standard AWS default credential provider chain: environment variables (AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY/AWS_SESSION_TOKEN), shared credentials and config files (including SSO), web identity federation (for EKS IRSA or GitHub Actions), ECS container credentials, and EC2 instance metadata. In other words: wherever your AWS credentials normally come from, they will be found. There is also an API-key path — keys generated in the AWS Console can be passed as api_key= or via ANTHROPIC_AWS_API_KEY — and constructor arguments always win over environment variables. The full precedence order is in the environment variable reference.
Troubleshooting the first request
| Symptom | Likely cause |
|---|---|
Error at AnthropicAWS() construction | Missing AWS_REGION or ANTHROPIC_AWS_WORKSPACE_ID |
| "Outbound web identity federation is disabled for your account" | One-time account prerequisite not run: aws iam enable-outbound-web-identity-federation |
| Generic signature-rejection error | SigV4 region doesn't match the endpoint region |
| 403 | Request reached the server: wrong workspace ID, or the IAM principal lacks the needed action (e.g. aws-external-anthropic:CreateInference) |
The federation error is the most common first-day failure — it must be enabled once per AWS account before any request succeeds. A 403 is good news in disguise: networking, signing, and federation all worked, and you are down to checking the workspace ID and the IAM policy on your role. First-party sk-ant-api... keys do not work on this endpoint, so don't chase that path.
Where to go next
Harden access with IAM policy templates, understand the credential chain in depth, or see the first-API-call walkthrough for the request anatomy.