Use WIF with AWS

AWS workloads can authenticate to the Claude API without static API keys by exchanging an AWS-signed OIDC identity token. The recommended path calls the AWS STS GetWebIdentityToken API, which works anywhere the workload has AWS credentials: Lambda, EC2, ECS, and EKS. EKS workloads can alternatively use the Kubernetes projected-token path, which has fewer configuration steps but only works inside a pod.

This guide shows both paths. For the underlying concepts (service accounts, federation issuers, and federation rules), see Workload Identity Federation.

Prerequisites

• Familiarity with WIF concepts: service accounts, federation issuers, and federation rules.
• An AWS workload (EKS pod, ECS task, Lambda function, or EC2 instance) with an attached IAM role.
• The aws CLI or an AWS SDK available in the workload.
• Permission to create service accounts, federation issuers, and federation rules in the Claude Console for your Anthropic organization.

Use STS web identity tokens (recommended)

The AWS STS GetWebIdentityToken API returns an OIDC token signed by AWS that asserts the caller's IAM identity. Because it uses the workload's ambient AWS credentials, the same integration covers Lambda, EC2, ECS, and EKS.

Configure AWS

Configure Anthropic

Follow the setup walkthrough to register a federation issuer, create an Anthropic service account, and create a federation rule in the Claude Console. Use these STS-specific values.

Federation issuer: Register the per-account STS issuer URL you copied in the prior step. It exposes a public JWKS endpoint, so use discovery mode.

{
  "name": "aws-sts",
  "issuer_url": "https://<uuid>.tokens.sts.global.api.aws",
  "jwks_source": "discovery"
}

Federation rule: Match the audience you pass to GetWebIdentityToken and the calling role's IAM role ARN in the sub claim. The sub value is the IAM role ARN of the workload that called the API, in the form arn:aws:iam::<account>:role/<role-name>. The token also carries an https://sts.amazonaws.com/ claim with aws_account, org_id, principal_id, and any request_tags you passed; you can match on those with the rule's claims map or a CEL condition for finer control.

{
  "name": "prod-inference",
  "issuer_id": "fdis_...",
  "match": {
    "subject_prefix": "arn:aws:iam::123456789012:role/inference-worker",
    "audience": "https://api.anthropic.com"
  },
  "target": { "type": "service_account", "service_account_id": "svac_..." },
  "workspace_id": "wrkspc_...",
  "oauth_scope": "workspace:developer",
  "token_lifetime_seconds": 600
}

Be as specific as the workload allows. Match the exact role ARN, and only broaden subject_prefix (for example, to arn:aws:iam::123456789012:role/*) if multiple IAM roles should map to the same Anthropic service account.

Acquire and use the token

Call GetWebIdentityToken with https://api.anthropic.com as the audience, then pass the result to the SDK's federation credentials. The token provider is a callable, so the SDK re-invokes STS on each refresh.

import os

import anthropic
import boto3
from anthropic import WorkloadIdentityCredentials


def get_sts_web_identity_token() -> str:
    sts = boto3.client("sts", region_name="us-east-1")
    resp = sts.get_web_identity_token(
        Audience=["https://api.anthropic.com"],
        SigningAlgorithm="RS256",
        DurationSeconds=900,
    )
    return resp["WebIdentityToken"]


client = anthropic.Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=get_sts_web_identity_token,
        federation_rule_id=os.environ["ANTHROPIC_FEDERATION_RULE_ID"],
        organization_id=os.environ["ANTHROPIC_ORGANIZATION_ID"],
        service_account_id=os.environ["ANTHROPIC_SERVICE_ACCOUNT_ID"],
    ),
)

message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from AWS"}],
)
print(message.content[0].text)

Verify the setup

From inside the workload, exchange an STS-issued token directly and inspect the response:

JWT=$(aws sts get-web-identity-token \
  --region us-east-1 \
  --audience "https://api.anthropic.com" \
  --signing-algorithm RS256 \
  --duration-seconds 900 \
  --query WebIdentityToken --output text)

curl -sS https://api.anthropic.com/v1/oauth/token \
  -H "content-type: application/json" \
  -d "{
    \"grant_type\": \"urn:ietf:params:oauth:grant-type:jwt-bearer\",
    \"assertion\": \"$JWT\",
    \"federation_rule_id\": \"fdrl_...\",
    \"organization_id\": \"00000000-0000-0000-0000-000000000000\",
    \"service_account_id\": \"svac_...\"
  }" | jq

A successful exchange returns an access_token beginning with sk-ant-oat01- and an expires_in value in seconds. On 400 invalid_grant, see Troubleshoot a failed exchange; the most common AWS-side cause is an iss mismatch (the per-account STS issuer URL must match the registered issuer_url exactly).

Use EKS projected service-account tokens

If your workload runs in an EKS pod, you can skip the STS call and read a Kubernetes-projected service-account token directly from disk. Kubernetes natively projects an OIDC-compatible token into the pod, and the SDK can read it from a file path, so no token-provider callable is required. This path has two fewer AWS configuration steps than the STS path but only works inside a pod; the underlying mechanism is the same as the generic Kubernetes integration.

This path additionally requires an EKS cluster with an IAM OIDC provider enabled and kubectl access to the cluster.

Configure your EKS cluster

Configure Anthropic

Follow the setup walkthrough to register a federation issuer, create an Anthropic service account, and create a federation rule in the Claude Console. Use these EKS-specific values.

Federation issuer: EKS issuers expose a public JWKS endpoint, so use discovery mode. The issuer URL must exactly match the token's iss claim. Register one issuer per cluster.

{
  "name": "prod-eks-uswest2",
  "issuer_url": "https://oidc.eks.us-west-2.amazonaws.com/id/6FA42E7BFDE8549CB...",
  "jwks_source": "discovery"
}

Federation rule: Match the Kubernetes sub claim and the Anthropic audience https://api.anthropic.com. (Project a dedicated service-account token with that audience; don't reuse the IRSA default sts.amazonaws.com token.)

{
  "name": "prod-inference",
  "issuer_id": "fdis_...",
  "match": {
    "subject_prefix": "system:serviceaccount:inference:inference-worker",
    "audience": "https://api.anthropic.com"
  },
  "target": { "type": "service_account", "service_account_id": "svac_..." },
  "workspace_id": "wrkspc_...",
  "oauth_scope": "workspace:developer",
  "token_lifetime_seconds": 600
}

Be as specific as the workload allows. Loosen subject_prefix to system:serviceaccount:inference:* (the trailing * makes it a prefix match) only if every service account in the namespace should map to the same Anthropic service account.

Acquire and use the token

Inside the pod, the projected token is at /var/run/secrets/anthropic.com/token (exposed as ANTHROPIC_IDENTITY_TOKEN_FILE in the Pod spec). Pass that file to the SDK's federation credentials and the SDK handles the exchange and refresh.

import os

import anthropic
from anthropic import IdentityTokenFile, WorkloadIdentityCredentials

client = anthropic.Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=IdentityTokenFile(
            os.environ["ANTHROPIC_IDENTITY_TOKEN_FILE"]
        ),
        federation_rule_id=os.environ["ANTHROPIC_FEDERATION_RULE_ID"],
        organization_id=os.environ["ANTHROPIC_ORGANIZATION_ID"],
        service_account_id=os.environ["ANTHROPIC_SERVICE_ACCOUNT_ID"],
    ),
)

message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from EKS"}],
)
print(message.content[0].text)

Verify the setup

From inside the pod, exchange the projected token directly and inspect the response:

JWT=$(cat "$ANTHROPIC_IDENTITY_TOKEN_FILE")

curl -sS https://api.anthropic.com/v1/oauth/token \
  -H "content-type: application/json" \
  -d "{
    \"grant_type\": \"urn:ietf:params:oauth:grant-type:jwt-bearer\",
    \"assertion\": \"$JWT\",
    \"federation_rule_id\": \"$ANTHROPIC_FEDERATION_RULE_ID\",
    \"organization_id\": \"$ANTHROPIC_ORGANIZATION_ID\",
    \"service_account_id\": \"$ANTHROPIC_SERVICE_ACCOUNT_ID\"
  }" | jq

A successful exchange returns an access_token beginning with sk-ant-oat01- and an expires_in value in seconds. On 400 invalid_grant, see Troubleshoot a failed exchange; the most common EKS-side cause is the projected token's aud not matching the rule (project a token with audience: https://api.anthropic.com, not the IRSA default sts.amazonaws.com).

Scope your rule

Lock the rule's match block to the narrowest scope that fits your use case:

• Pin the full role ARN: Use subject_prefix: "arn:aws:iam::<account>:role/<role-name>" with no trailing * so other roles in the account do not match.
• Pin the account ID: Match the aws_account field of the token's https://sts.amazonaws.com/ claim via the claims map or a CEL condition as a defense-in-depth check against a misconfigured prefix.
• Pin namespace and service account on EKS: Use the exact system:serviceaccount:<namespace>:<name> value with no * after the system:serviceaccount: prefix.
• Use a separate rule per environment: Create distinct rules for production, staging, and development workloads rather than widening one prefix to cover them all.

Next steps

• Review the WIF reference for the full credential precedence, profile configuration, and rule matching reference.
• For self-managed Kubernetes clusters that aren't on EKS, see Use WIF with Kubernetes.