When a team sets up Claude Platform on AWS, the configuration surface is deliberately small: the SDK needs AWS_REGION and ANTHROPIC_AWS_WORKSPACE_ID set in the environment, and it needs ordinary AWS credentials available for signing. That is the whole list. Understanding why those pieces suffice — and what happens when one is missing — is most of what there is to know about auth on this platform.
SigV4: the signature your stack already uses
AWS Signature Version 4 (SigV4) is the request-signing scheme behind essentially every AWS API call your organization already makes. Instead of attaching a static API key to a request, the SDK cryptographically signs each request using the AWS credentials available in its environment — typically the IAM role attached to the compute the code runs on. The receiving service verifies the signature and knows exactly which AWS identity sent the request.
For your security team, this is the headline: there is no Claude API key. Nothing to issue, store in a vault, rotate on a schedule, or leak in a repository. Credential lifecycle, scoping, and revocation are all handled by the IAM discipline you already operate — a workload's access to Claude ends the same way its access to any AWS service ends. Developers authenticate as themselves; production workloads authenticate as their roles.
What the workspace ID is for
The one concept that is new is the workspace. Signing proves who is calling; the workspace ID says which of your organization's workspaces the request belongs to, so the platform can attribute usage to the right context on the Anthropic-operated side. The SDK reads it from the ANTHROPIC_AWS_WORKSPACE_ID environment variable rather than a constructor argument, which is a quiet piece of good design: the workspace becomes deployment configuration, not code. The same application image can run in a dev workspace and a production workspace with nothing changed but the environment.
Treat workspace IDs the way you treat other environment configuration — defined per environment in your deployment tooling, not hard-coded. A workspace ID is not a secret in the way an API key is (it cannot authenticate anything by itself; SigV4 does that), but it does determine attribution, so keeping dev and production values cleanly separated matters for the same reason separate AWS accounts do.
The two variables in practice
With the environment prepared, the client constructor takes no arguments at all.
from anthropic import AnthropicAWS
# Requires in the environment:
# AWS_REGION e.g. "us-east-1"
# ANTHROPIC_AWS_WORKSPACE_ID your workspace's ID
# plus standard AWS credentials (an attached IAM role in production).
client = AnthropicAWS()
message = client.messages.create(
model="claude-sonnet-5",
max_tokens=512,
messages=[{"role": "user", "content": "Reply with OK."}],
)
print(message.content)Model IDs are the bare first-party form (claude-sonnet-5, claude-opus-4-8, claude-haiku-4-5) — only Bedrock prefixes them with anthropic..
Why this design is good news for your review
Compare the audit conversation across credential models. With API keys (Foundry's model), the security review must cover issuance, storage, rotation, and leak response. With SigV4, those questions collapse into your existing AWS identity story: short-lived signed requests, credentials from roles, revocation through IAM. Combined with the workspace ID providing clean per-environment attribution, the platform adds essentially zero new credential surface to an AWS estate — which, alongside same-day feature parity, is the core of its appeal.
Where to go next
See the full platform picture in Claude Platform on AWS: Anthropic-Operated, AWS-Resident, or go straight to a working request with Your First Call on Claude Platform on AWS. The quickstart covers the equivalent first steps on all four platforms.