Claude Platform on AWS authenticates with AWS credentials via SigV4 request signing, or with API keys generated in the AWS Console. Both credential types can be long-lived, and anything long-lived eventually needs rotating — because of a policy clock, a departed employee, or a suspected leak. The good news: because auth runs through AWS's standard credential machinery, the rotation playbooks your team already knows apply directly.
First choice: don't rotate — use roles
Before building rotation automation, check whether you need static keys at all. The SDK clients resolve credentials through the AWS default provider chain: environment variables, shared credential files (including SSO and credential_process), web identity (IRSA on Kubernetes, GitHub Actions OIDC), ECS container credentials, and EC2 instance metadata. Workloads running on EC2, ECS, Lambda, or EKS can use IAM roles that issue short-lived, auto-refreshed credentials — nothing to rotate, nothing to leak from a config file. The x-amz-security-token header that temporary credentials require is handled automatically by the SDK clients.
The dual-key pattern for IAM access keys
When you do hold static access keys, AWS lets each IAM user have two active access keys at once — which is exactly what makes zero-downtime rotation possible. The sequence:
1. Create the second key. The old key keeps working; nothing changes for your application yet.
2. Verify the new key against Claude Platform on AWS before touching production. A cheap, low-risk probe is a token count or model lookup rather than a full inference call:
from anthropic import AnthropicAWS
# New key supplied via constructor for the verification step
client = AnthropicAWS(
aws_access_key="AKIA...NEW",
aws_secret_access_key="...",
)
print(client.models.list()) # succeeds -> new key signs correctlyA success proves the key is active, the SigV4 signature is accepted, and the principal still has its IAM actions. A 403 here means the request reached the server but was refused — check the workspace ID and the principal's IAM policy before proceeding.
3. Roll the new key out to your application's configuration (ideally a single secrets-manager entry that all instances read).
4. Deactivate — don't delete — the old key. Watch for authentication failures. If something you forgot still used the old key, reactivating it is instant; recreating a deleted key is not possible.
5. Delete the old key once you're confident nothing references it.
Automating with Secrets Manager
AWS Secrets Manager can run this dance on a schedule: store the access key pair as a secret, attach a rotation function that performs the create-verify-swap-deactivate steps, and have applications fetch the secret at startup (or on a refresh interval) instead of baking keys into environment files. The important design point is the verification step — your rotation function should make a real signed call to the Claude Platform endpoint with the candidate credentials and only promote them on success, so a mis-provisioned key can never become the live one. Consult the AWS Secrets Manager documentation for the rotation-function mechanics.
Rotating platform API keys and short-term tokens
Claude Platform on AWS also supports API-key authentication as an alternative to SigV4. These keys are generated and managed in the AWS Console (Claude Platform on AWS → API keys), not the Claude Console — first-party sk-ant-api... keys do not work here. The same dual-credential logic applies: issue a new key, verify it, swap, then revoke the old one. Any principal using API-key auth needs the aws-external-anthropic:CallWithBearerToken IAM action.
For handing credentials to a separate process — an LLM gateway or a bearer-token-only tool — consider short-term API keys instead of long-lived Console keys. AWS publishes token-generator libraries (Python, JavaScript, Java) that mint a time-limited token from your existing AWS credentials; the lifetime defaults to 12 hours and is capped at the lesser of the requested duration, the underlying AWS credentials' expiry, and 12 hours. Two caveats: the SDK does not refresh these tokens automatically — on expiry you generate a new token and construct a new client — and if the process could generate the token locally, it already has SigV4 credentials, so plain SigV4 is usually simpler.
Where to go next
See how the SDK resolves AWS credentials, short-term credentials via STS AssumeRole, and per-pod IAM roles with IRSA for the role-based setups that make rotation unnecessary.