Claude Platform on AWS is Anthropic-operated but authenticates through AWS: requests are SigV4-signed, and access is controlled by IAM policies. That design pays off in containerized environments. The SDK clients resolve credentials through the AWS default credential provider chain, which explicitly includes ECS container credentials — the temporary credentials that ECS injects for a task's IAM role. Your container picks them up automatically, signs each request, and rotates credentials without any code on your side.
Task role, not execution role
ECS gives every task two potential roles, and they are easy to confuse. The execution role is what the ECS agent itself uses — pulling container images, writing logs. The task role is what your application code assumes at runtime. Claude permissions belong on the task role. This is the whole point of the pattern: each service in your cluster gets its own task role, and each task role gets exactly the Claude access that service needs — one workspace, a specific set of actions, nothing more. Two services in the same cluster can have entirely different Claude permissions without either being able to borrow the other's.
A minimal task-role policy
The IAM namespace is aws-external-anthropic and the single resource type is the workspace. A service that only performs inference needs this much:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"aws-external-anthropic:CreateInference",
"aws-external-anthropic:CountTokens",
"aws-external-anthropic:GetModel",
"aws-external-anthropic:ListModels",
"aws-external-anthropic:GetWorkspace"
],
"Resource": "arn:aws:aws-external-anthropic:us-west-2:123456789012:workspace/wrkspc_01AbCdEf23GhIj"
}]
}Scoping to a workspace ARN is what makes multi-tenant or multi-environment setups clean: give the production service the production workspace ARN and the staging service the staging one, and usage, quotas, cost, files, and batches all roll up per workspace. If you use AWS managed policies instead, know their shape: AnthropicInferenceAccess is the narrowest managed policy sufficient for inference, but it is granted on Resource: "*" and its Get*/List* wildcards can read all workspace content — file bytes, batch results, session history. For per-service isolation, prefer a custom policy on the workspace ARN.
No secrets in the task definition
Because SigV4 signing uses the task role's credentials, there is no API key to inject — not as a container environment variable, not from a secrets manager. The only Claude-specific values in the task definition are two pieces of non-secret configuration the AnthropicAWS client requires: ANTHROPIC_AWS_WORKSPACE_ID (the wrkspc_... identifier) and AWS_REGION set to the workspace's bound region. Neither grants access by itself; a stolen task definition reveals nothing usable. In application code, the client needs no arguments at all:
from anthropic import AnthropicAWS
client = AnthropicAWS() # task role + env vars do the rest
reply = client.messages.create(
model="claude-haiku-4-5",
max_tokens=512,
messages=[{"role": "user", "content": "Classify this ticket: ..."}],
)Two operational notes. First, the one-time account prerequisite applies here as everywhere: outbound web identity federation must be enabled on the AWS account (aws iam enable-outbound-web-identity-federation) or every request fails. Second, the workspace's region and the SigV4 signing region must match — pin AWS_REGION to the workspace's region even if your cluster runs elsewhere.
Keeping traffic private
By default your tasks reach the endpoint (https://aws-external-anthropic.{region}.api.aws) over the public internet path. If your Fargate tasks run in private subnets, AWS PrivateLink is supported for connecting a VPC to the Claude Platform on AWS endpoint, so Claude traffic can stay on your VPC's private connectivity like any other internal dependency. For audit, note that inference calls are CloudTrail data events — you must explicitly enable (paid) data event logging to see them; only workspace, vault, and webhook actions log as default-on management events.
When a sidecar or gateway needs a token instead
Occasionally a component in your task cannot SigV4-sign — a third-party gateway container or a tool that only speaks bearer tokens. For that case, the platform supports short-term API keys generated from AWS credentials: AWS publishes token-generator libraries (Python among them) that read the task role's credentials via the standard provider chain and return a time-limited token, capped at 12 hours or the credentials' own expiry, whichever is shorter. The consuming principal additionally needs the aws-external-anthropic:CallWithBearerToken action. But note the documentation's own caveat: if the process can generate the token locally, it already holds SigV4 credentials, so plain SigV4 is usually the simpler and safer default. Reserve tokens for genuine hand-offs to processes that cannot sign.
Where to go next
The same credential chain serves Lambda functions and EKS with IRSA. For designing the workspace layout your task roles point at, see workspace isolation strategies. Token hand-offs are covered in short-term credentials.