AWSでWIFを使用する

AWSワークロードは、AWSが署名したOIDCアイデンティティトークンを交換することで、静的なAPIキーなしでClaude APIに対して認証できます。推奨される方法はAWS STSのGetWebIdentityToken APIを呼び出すもので、ワークロードがAWS認証情報を持つあらゆる場所（Lambda、EC2、ECS、EKS）で機能します。EKSワークロードは代わりにKubernetesプロジェクテッドトークンの方法を使用することもできます。こちらは設定手順が少ないですが、Pod内でのみ機能します。

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



前提条件

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



STS Webアイデンティティトークンを使用する（推奨）

AWS STSのGetWebIdentityToken APIは、呼び出し元のIAMアイデンティティを表明する、AWSが署名したOIDCトークンを返します。ワークロードの環境にあるAWS認証情報を使用するため、同じ統合でLambda、EC2、ECS、EKSをカバーできます。



AWSを設定する



Anthropicを設定する

Claude ConsoleでSettings → Workload identityを開き、Connect workloadをクリックして、AWSタイルを選択します。ウィザードが発行者の登録、サービスアカウントの作成、フェデレーションルールの作成を順に案内します。

ウィザードがこれらのリソースを作成します。ウィザードに入力する場合でも、Admin API に送信する場合でも、以下の値を使用してください。

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

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

フェデレーションルール： GetWebIdentityTokenに渡すオーディエンスと、subクレーム内の呼び出し元ロールのIAMロールARNをマッチさせます。subの値は、APIを呼び出したワークロードのIAMロールARNで、arn:aws:iam::<account>:role/<role-name>という形式です。トークンにはaws_account、org_id、principal_id、および渡したrequest_tagsを含むhttps://sts.amazonaws.com/クレームも含まれています。より細かい制御のために、ルールの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-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from AWS"}],
)
print(next(block.text for block in message.content if block.type == "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プロジェクテッドサービスアカウントトークンを使用する

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

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



EKSクラスターを設定する



Anthropicを設定する

Claude ConsoleでSettings → Workload identityを開き、Connect workloadをクリックして、AWSタイルを選択します。ウィザードが発行者の登録、サービスアカウントの作成、フェデレーションルールの作成を順に案内します。

ウィザードがこれらのリソースを作成します。ウィザードに入力する場合でも、Admin API に送信する場合でも、以下の値を使用してください。

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

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

フェデレーションルール： KubernetesのsubクレームとAnthropicのオーディエンスhttps://api.anthropic.comをマッチさせます。（そのオーディエンスを持つ専用のサービスアカウントトークンをプロジェクトしてください。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内では、プロジェクトされたトークンは/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-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello from EKS"}],
)
print(next(block.text for block in message.content if block.type == "text"))



セットアップを検証する

Pod内から、プロジェクトされたトークンを直接交換してレスポンスを確認します：

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側で最も一般的な原因は、プロジェクトされたトークンのaudがルールと一致していないことです（IRSAのデフォルトであるsts.amazonaws.comではなく、audience: https://api.anthropic.comを持つトークンをプロジェクトしてください）。



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

ルールの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を使用するを参照してください。