Claude Platform on AWS has an unusual shape: you authenticate to an AWS front door with ordinary AWS credentials, but the models run on Anthropic-managed infrastructure behind it. That split creates an identity-relay problem. AWS verifies your SigV4 signature — but Anthropic's side also needs a trustworthy statement of who is calling, in a form it can verify without having access to your AWS account. The mechanism that solves this is outbound web identity federation, and it is disabled by default in every AWS account.
What actually happens on each request
When your SigV4-signed request arrives at the gateway (aws-external-anthropic.{region}.api.aws), AWS validates the signature and then calls sts:GetWebIdentityToken server-side — you never call it yourself — to mint a short-lived JWT (JSON Web Token, a signed identity document) representing your AWS principal. That JWT is forwarded to Anthropic along with your request, giving Anthropic's infrastructure cryptographic proof of the caller's AWS identity without Anthropic ever touching your credentials. This is "outbound" federation in AWS STS terms: instead of outside identities federating into AWS, an AWS identity is being asserted outward to an external service.
Because that STS capability is off by default, the whole relay fails until someone enables it — and since the gateway needs it on every SigV4 call, nothing works before then, no matter how correct the rest of your setup is.
The one-time fix
# Run once per AWS account, by a principal with IAM admin rights
aws iam enable-outbound-web-identity-federation
# Verify state (and see the issuer URL AWS will use)
aws iam get-outbound-web-identity-federation-infoThat's the entire remediation: one CLI call, once per AWS account (not per region, workspace, user, or application). The companion get-outbound-web-identity-federation-info command confirms federation is enabled and shows the issuer URL, which is also the check to script into your account-baseline automation if you provision many accounts.
Recognizing the failure
The error is refreshingly explicit for once: requests fail with a message that outbound web identity federation is disabled for your account. Anthropic's documentation calls this the most common setup error on the platform. The trap is that teams read "federation" and go hunting through their own identity provider configuration, IAM roles, or SSO setup — when the fix is the account-level toggle above. If you see that message, do not debug your credentials; enable federation and retry.
| Symptom | Likely cause | Where to look |
|---|---|---|
| "Outbound web identity federation is disabled for your account" | This prerequisite | aws iam enable-outbound-web-identity-federation |
| Generic signature rejection | Service name or region mismatch in SigV4 | SigV4 service name |
403 naming an IAM action | Missing aws-external-anthropic:* permission | IAM actions reference |
What it means for governance
Enabling the switch is a deliberate, auditable act: your account is authorizing STS to assert its identities to an external party for this service's auth flow. Security teams reviewing the platform should note three reassuring properties. The JWT is minted server-side by AWS during request handling, so there is no new credential for your applications to hold, leak, or rotate. What is forwarded is an identity assertion, not your keys — Anthropic never receives AWS credentials. And per-caller authorization still lives entirely in your IAM policies on the aws-external-anthropic action namespace; federation being enabled grants nobody any new permissions by itself.
aws iam enable-outbound-web-identity-federation in the account-setup phase of your rollout — alongside the Marketplace subscription and workspace creation — not in application deployment docs. It needs IAM-admin privileges that application teams shouldn't have, and it only ever needs to run once.Where to go next
The full setup sequence lives in subscribing via AWS Marketplace and your first API call on Claude Platform on AWS; for the other classic day-one failures, see common setup errors.