AWSでWIFを使用する

AWSワークロードは、AWSが署名したOIDC IDトークンを交換することで、静的なAPIキーを使用せずにClaude APIに対して認証できます。推奨される方法は、AWS STSのGetWebIdentityToken APIを呼び出すことです。これは、ワークロードがAWS認証情報を持っている場所であればどこでも機能します（Lambda、EC2、ECS、EKS）。EKSワークロードは、代わりにKubernetesのprojected tokenを使用する方法を利用することもできます。この方法は設定手順が少なくて済みますが、Pod内でのみ機能します。

このガイドでは両方の方法を説明します。基礎となる概念（サービスアカウント、フェデレーション発行者、フェデレーションルール）については、Workload Identity Federationを参照してください。

前提条件

• WIFの概念（サービスアカウント、フェデレーション発行者、フェデレーションルール）に精通していること。
• IAMロールがアタッチされたAWSワークロード（EKS Pod、ECSタスク、Lambda関数、またはEC2インスタンス）。
• ワークロード内でaws CLIまたはAWS SDKが利用可能であること。
• Anthropic組織のClaude Consoleでサービスアカウント、フェデレーション発行者、フェデレーションルールを作成する権限。

STS Web IDトークンを使用する（推奨）

AWS STSのGetWebIdentityToken APIは、呼び出し元のIAM IDをアサートする、AWSが署名したOIDCトークンを返します。ワークロードのアンビエントAWS認証情報を使用するため、同じ統合でLambda、EC2、ECS、EKSをカバーできます。

AWSを設定する

Anthropicを設定する

セットアップ手順に従って、Claude Consoleでフェデレーション発行者を登録し、Anthropicサービスアカウントを作成し、フェデレーションルールを作成します。以下のSTS固有の値を使用してください。

フェデレーション発行者： 前のステップでコピーしたアカウントごとのSTS発行者URLを登録します。公開JWKSエンドポイントを公開しているため、ディスカバリーモードを使用します。

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

フェデレーションルール： GetWebIdentityTokenに渡すオーディエンスと、subクレーム内の呼び出し元ロールのIAMロールARNをマッチさせます。subの値は、APIを呼び出したワークロードのIAMロールARNで、arn:aws:iam::<account>:role/<role-name>という形式です。トークンにはhttps://sts.amazonaws.com/クレームも含まれており、aws_account、org_id、principal_id、および渡したrequest_tagsが含まれます。より細かい制御のために、ルールのclaimsマップまたはCELのconditionでこれらをマッチさせることができます。

{
  "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
}

ワークロードが許す限り具体的に指定してください。正確なロールARNをマッチさせ、複数のIAMロールを同じAnthropicサービスアカウントにマッピングする必要がある場合にのみ、subject_prefixを広げてください（例：arn:aws:iam::123456789012:role/*）。

トークンを取得して使用する

オーディエンスとしてhttps://api.anthropic.comを指定してGetWebIdentityTokenを呼び出し、その結果をSDKのフェデレーション認証情報に渡します。トークンプロバイダーは呼び出し可能オブジェクトであるため、SDKはリフレッシュのたびにSTSを再度呼び出します。

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"],
        workspace_id=os.environ.get("ANTHROPIC_WORKSPACE_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)

セットアップを検証する

ワークロード内から、STSが発行したトークンを直接交換し、レスポンスを確認します。

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_...\",
    \"workspace_id\": \"wrkspc_...\"
  }" | jq

交換が成功すると、sk-ant-oat01-で始まるaccess_tokenと、秒単位のexpires_in値が返されます。400 invalid_grantが返された場合は、失敗した交換のトラブルシューティングを参照してください。AWS側で最も一般的な原因はissの不一致です（アカウントごとのSTS発行者URLが、登録されたissuer_urlと正確に一致している必要があります）。

EKSのprojected service accountトークンを使用する

ワークロードがEKS Pod内で実行されている場合、STS呼び出しをスキップして、Kubernetesがprojectしたサービスアカウントトークンをディスクから直接読み取ることができます。KubernetesはOIDC互換のトークンをネイティブにPodにprojectし、SDKはファイルパスからそれを読み取ることができるため、トークンプロバイダーの呼び出し可能オブジェクトは不要です。この方法はSTSの方法よりもAWS設定手順が2つ少なくて済みますが、Pod内でのみ機能します。基礎となるメカニズムは汎用Kubernetes統合と同じです。

この方法では、さらにIAM OIDCプロバイダーが有効になっているEKSクラスターと、クラスターへのkubectlアクセスが必要です。

EKSクラスターを設定する

Anthropicを設定する

セットアップ手順に従って、Claude Consoleでフェデレーション発行者を登録し、Anthropicサービスアカウントを作成し、フェデレーションルールを作成します。以下のEKS固有の値を使用してください。

フェデレーション発行者： EKS発行者は公開JWKSエンドポイントを公開しているため、ディスカバリーモードを使用します。発行者URLはトークンのissクレームと正確に一致する必要があります。クラスターごとに1つの発行者を登録してください。

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

フェデレーションルール： KubernetesのsubクレームとAnthropicオーディエンスhttps://api.anthropic.comをマッチさせます。（そのオーディエンスを持つ専用のサービスアカウントトークンをprojectしてください。IRSAのデフォルトであるsts.amazonaws.comトークンを再利用しないでください。）

{
  "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
}

ワークロードが許す限り具体的に指定してください。名前空間内のすべてのサービスアカウントを同じAnthropicサービスアカウントにマッピングする必要がある場合にのみ、subject_prefixをsystem:serviceaccount:inference:*に緩めてください（末尾の*によりプレフィックスマッチになります）。

トークンを取得して使用する

Pod内では、projectされたトークンは/var/run/secrets/anthropic.com/tokenにあります（Pod仕様でANTHROPIC_IDENTITY_TOKEN_FILEとして公開されています）。そのファイルをSDKのフェデレーション認証情報に渡すと、SDKが交換とリフレッシュを処理します。

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"],
        workspace_id=os.environ.get("ANTHROPIC_WORKSPACE_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)

セットアップを検証する

Pod内から、projectされたトークンを直接交換し、レスポンスを確認します。

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\",
    \"workspace_id\": \"$ANTHROPIC_WORKSPACE_ID\"
  }" | jq

交換が成功すると、sk-ant-oat01-で始まるaccess_tokenと、秒単位のexpires_in値が返されます。400 invalid_grantが返された場合は、失敗した交換のトラブルシューティングを参照してください。EKS側で最も一般的な原因は、projectされたトークンのaudがルールと一致していないことです（IRSAのデフォルトであるsts.amazonaws.comではなく、audience: https://api.anthropic.comを持つトークンをprojectしてください）。

ルールのスコープを設定する

ルールのmatchブロックを、ユースケースに適した最も狭いスコープに制限してください。

• 完全なロールARNを固定する： 末尾に*を付けずにsubject_prefix: "arn:aws:iam::<account>:role/<role-name>"を使用し、アカウント内の他のロールがマッチしないようにします。
• アカウントIDを固定する： プレフィックスの設定ミスに対する多層防御として、claimsマップまたはCELのconditionを介して、トークンのhttps://sts.amazonaws.com/クレームのaws_accountフィールドをマッチさせます。
• EKSで名前空間とサービスアカウントを固定する： system:serviceaccount:プレフィックスの後に*を付けずに、正確なsystem:serviceaccount:<namespace>:<name>値を使用します。
• 環境ごとに個別のルールを使用する： 1つのプレフィックスを広げてすべてをカバーするのではなく、本番、ステージング、開発のワークロードごとに個別のルールを作成します。

次のステップ

• 認証情報の優先順位、プロファイル設定、ルールマッチングの完全なリファレンスについては、WIFリファレンスを確認してください。
• EKS以外のセルフマネージドKubernetesクラスターについては、KubernetesでWIFを使用するを参照してください。