Claude Platform on AWS の IAM 認証パターンがたくさんあるので整理してみた

こんにちは、せーのです。今日は Claude Platform on AWS（いわゆる Claude on AWS）を触っていて、「結局この接続パターンだと IAM は何が必要なの？」と思うことが多いので整理してみようと思います。

https://dev.classmethod.jp/articles/claude-code-claude-platform-on-aws-sigv4/

こちらの記事にもあるように、Claude Platform on AWSの最大の特徴としては「IAMで認証できる」ということだと思います。API KEYを発行しなくてもAWSの認証の仕組みを使って短期的な認証を出せることはセキュリティ的にも大変ありがたいことです。

そして

https://dev.classmethod.jp/articles/claude-desktop-on-claude-platform-on-aws/

こちらにもあるように、Claude Platform on AWSはターミナルのClaude Codeを始め、Claude DesktopやClaude Platformとも繋げられます。当然AWSリソースからClaude Platform on AWSを呼び出せばIAMの仕組みのみでClaudeを使うことができます。

ただ、ここで注意すべき点は、それぞれのプラットフォームやリソースアクセスに対する認可、というのはそれぞれ違います。Claude Desktopに対する認可ポリシーと、Lambdaに対する認可ポリシーは違う、ということですね。

Bedrock で Claude を叩くときの bedrock:* のイメージが強いと、aws-external-anthropic:* の世界に入った瞬間にポリシー設計がブレやすいです。なのでこの記事では、接続方法ごとに必要な IAM アクションを逆引きするのを主目的にします。あわせて、末尾で 実機の疎通結果もまとめます。

前提: Workspace は「請求・レート制限・IAM の境界線」

IAM の話に入る前に、Claude Platform on AWS の Workspace という概念を押さえておきます。後続のポリシー例で出てくる wrkspc_xxxxxxxxxx や workspace ARN は、すべてこの Workspace を指しています（出典: Workspaces - Claude Platform on AWS）。

ざっくり言うと、Workspace は Claude Platform on AWS における論理的な分離単位で、次のものがすべて Workspace ごとに独立します。

組織あたり最大100 Workspace まで作れて、サインアップ時に Default Workspace が1つ自動作成されます（Default は削除・リネーム不可）。

どういう区切りで使い分けるか

典型的なパターンは次の4つです。

• 環境別（dev / stg / prod）: 本番だけ支出制限を高めにする、開発者ロールは prod Workspace を叩けないように IAM で縛る、といった設計が素直に作れます
• プロジェクト・チーム別: 社内の複数プロジェクトで月次コストを切り出したい場合
• 顧客別（マルチテナント SaaS）: テナント = Workspace にすると、顧客の Files が他テナントから見えない、顧客ごとに月額予算を区切れる、IAM Condition で「このロールは customer-a Workspace しか叩けない」と縛れる、という形が作れます
• ユースケース別（チャット用 / バッチ用 / Agent 用）: バッチ処理が暴走しても対話用 Workspace の RPM を食わない、という分離ができます

後に出てきますが「単一ワークスペースに絞る」というのは例えば、開発用のワークスペースのみ触れることで、本番の支出に影響させない、Filesを混ぜてしまうような事故を防ぐことができる、というような意味ですね。

リージョン制約の注意

Workspace は 1リージョン固定です。Tokyo（ap-northeast-1）で作った Workspace は Tokyo のエンドポイントからしか叩けず、東京とバージニアの両方で使いたければそれぞれのリージョンで Workspace を作る必要があります（Workspace ID も別物になる）。

つまり後で出てくる「workspace ARN で Resource を絞る」は、実質「単一リージョン × 単一論理分離単位への絞り込み」という意味になります。

4つの接続パターン早見表

Claude Platform on AWS に「届く」経路は大きく分けて次の4つです。認証方式が違うので、必要な IAM アクションもセットが変わります。

どのパターンも、到達先のイメージとしては同一エンドポイント https://aws-external-anthropic.<region>.api.aws に向かう、という整理になります。

補足として、早見表の SigV4 行は aws-external-anthropic:CreateInference を主に指す略記です。公式 Python SDK の AnthropicAWS で推論リクエストを送る経路では、Outbound Web Identity Federation により、呼び出し元の IAM プリンシパルに sts:GetWebIdentityToken と sts:TagGetWebIdentityToken を許可したポリシーが別途必要です（根拠と経路ごとの整理は次節、実機は「実験A」）。早見表だけで STS を省略しないでください。

SigV4とSTSの関係

SigV4は、HTTP リクエストに「このクレデンシャルの持ち主が送った正当なリクエストである」と示すための署名方式です。許可される API アクションは、署名の有無ではなく IAM のポリシー評価で決まります。

STSは、少なくとも次の二種類の役割が Claude Platform on AWS の文脈で出てきます。

1. 一時クレデンシャルの発行（例: Lambda 実行ロール、AssumeRole）
   署名に使うアクセスキー／シークレット／セッショントークンを渡す。許可内容そのものは IAM に付いたポリシーで定義され、STS はそのプリンシパル用の一時キーを返している、という整理です。

2. GetWebIdentityToken / TagGetWebIdentityToken
   Outbound Web Identity Federation の一環として、呼び出し元が STS API として Web identity 用トークンを取得するために必要です。これは「SigV4 と二択」ではなく、SigV4 で CreateInference に署名して送る SDK 経路でも、別途この STS API を呼ぶため、IAM に STS 用の Allow が無いと推論が失敗します。

公式の前提条件では、Claude Platform on AWS の ゲートウェイが STS を介したトークン発行に関わる旨が書かれています（出典: Prerequisites）。マネージドポリシー AnthropicInferenceAccess に caller 側の sts:GetWebIdentityToken / sts:TagGetWebIdentityToken が条件付きで含まれるのは、この経路を前提にしているためです。

経路ごとの違い（ポリシーに書くべき許可を言い切る）

まとめると、「SigV4 だから STS が不要」ではなく、署名（SigV4）と、Outbound federation 用の STS API 呼び出しは別レイヤーで、後者の許可が IAM に無いと AnthropicAWS や Bearer クライアント経路は通らない、という整理です。

ここから下は、早見表の各セルを 具体ポリシー例・マネージドポリシー・ARN の切り方で掘り下げます。

IAM アクションの名前空間は何か(おさらい)

結論から言うと、SigV4 で署名されるサービス名（IAM のアクション名前空間）としては aws-external-anthropic というものが出てきます。典型的には次のような形です。

aws-external-anthropic:CreateInference
aws-external-anthropic:AssumeConsole
aws-external-anthropic:CallWithBearerToken

Bedrock の bedrock: とは別物です。Bedrock 向けに作った IAM ポリシーをそのまま流用できるものではないので注意が必要です。

主要アクションの用途をざっくり表にします（詳細は公式の一覧 Actions, resources, and condition keys for Claude Platform on AWS が正です）。

SigV4 認証でできること（Claude Code / Lambda）

SigV4 は AWS の標準署名方式です。Lambda や EC2 では AWS デフォルト認証チェーンが効くので、基本は「実行ロール（またはインスタンスプロファイル等）に正しいポリシーを付ける」だけで、コードに長期キーを埋め込まなくてよい、という形になります。

SDK が辿る認証チェーンの優先順位はざっくり次のようなイメージです（公式ドキュメント AWS SDKs and Tools standardized credential providers 側の説明が本家です）。

1. 環境変数（AWS_ACCESS_KEY_ID など）
2. ~/.aws/credentials
3. Web identity（IRSA / GitHub Actions など）
4. ECS コンテナ認証情報（Lambda はここ）
5. EC2 IMDS

環境変数の例（Lambda など）

アプリ側で Claude on AWS 向けに切り替えるための環境変数として、例えば次のようなセットを置いてみます。

CLAUDE_CODE_USE_ANTHROPIC_AWS=1
ANTHROPIC_AWS_WORKSPACE_ID=wrkspc_xxxxxxxxxxxxx
AWS_REGION=ap-northeast-1

必要な IAM ポリシー例（単一ワークスペースに寄せる）

Lambda 実行ロールに付ける前提で、単一ワークスペースに寄せた例を置きます。Resource に workspace ARN を書けるのがポイントです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "aws-external-anthropic:CreateInference",
        "aws-external-anthropic:CountTokens",
        "aws-external-anthropic:Get*",
        "aws-external-anthropic:List*"
      ],
      "Resource": "arn:aws:aws-external-anthropic:ap-northeast-1:<account-id>:workspace/wrkspc_xxxxxxxxxxxxx"
    }
  ]
}

公式ユーザーガイドの「単一ワークスペース向け」の例は、まず aws-external-anthropic 側のアクションに絞って書かれています。一方で AnthropicAWS のように公式 SDK から推論する場合は、CreateInference だけでは足りず、マネージドポリシー AnthropicInferenceAccess と同様に、sts:GetWebIdentityToken と sts:TagGetWebIdentityToken を条件キー付きの別ステートメントで付与する必要があります（sts:IdentityTokenAudience や aws:CalledViaLast など）。理由は**「SigV4とSTSの関係」節の表**。本家は IAM policies for Claude on AWS の Managed policies 節です。

Bearer token 認証で増えるもの（Claude Desktop）

Claude Desktop はサードパーティ推論設定の Gateway 接続を使う形になりますが、ここで選べる Gateway auth scheme が bearer 固定で、SigV4 をネイティブに選ぶ口がありません（参考: Claude Desktop を Claude Platform on AWS 経由で使ってみた）。なので Claude Desktop からの経路は **Bearer token（API key を Authorization: Bearer ... で送る形式）**になります。

その場合に増えるのが CallWithBearerToken です。ここがないと、Bearer 経由のリクエストが CreateInference の前段で弾かれる、という整理になります。

違いを整理すると、SigV4 経路は CreateInference 周りが主役（Outbound federation 用の STS は**「SigV4とSTSの関係」節**）、Bearer 経路は CallWithBearerToken がゲートになり、その先で CreateInference が必要、というイメージです（プロトコルが違うだけで、最終的には同じ推論 API に届きます）。

Short-term API key と「完全 key-less」について

ここで誤解しやすいのが、「Bearer 経路 = 長期 API key を設定ファイルに置く必要がある」ではない、という点です。

Claude Desktop には Credential Helper という仕組みがあり、ローカルスクリプトから動的に Bearer token を返す構成が取れます。スクリプト側で token-generator-for-aws-external-anthropic を使い、IAM 認証情報から短期トークン（Short-term key、TTL 12時間）を生成できるので、設定ファイルに長期 API key を書かずに済みます（具体的なスクリプト例は前述の参考記事の Credential Helper 節にあります）。

運用上は「ユーザーが管理するのは IAM 認証情報だけ」になるので、かなり key-less に寄せられます。

ただ、Short-term でも結局は「IAM 認証情報 → 短期 Bearer token に変換」というステップが一度は入るので、Lambda の SigV4 のように そもそも鍵という概念がない、と同じ意味で「完全 key-less」と呼べるかは微妙、というのが個人的な感触です。プロトコル的にはあくまで Bearer なので、IAM 側で CallWithBearerToken を許可する必要がある点は変わりません。

整理すると、Claude Desktop で取れる選択肢は次の2つです。

「設定ファイルに静的な API key を置きたくない」が目的なら、Credential Helper で十分達成できる、という整理になります。

Claude Console フェデレーション（AssumeConsole）

Claude Console は、AWS のマネジメントコンソールから「サインイン」して入る、という導線があります。ここは IAM フェデレーションの話になります。

ざっくり流れだけ書くと、次のようなイメージです。

1. AWS マネジメントコンソールで IAM ログイン済み
2. 「サインイン」相当の操作で aws-external-anthropic:AssumeConsole を呼ぶ
3. AWS STS が Anthropic 向けの web identity token を発行
4. Claude Console がトークンを検証してログイン状態になる

AssumeConsole 側に付ける権限の例

Console 導線を許可する principal に対して、例えば次のような権限セットがあります。

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "aws-external-anthropic:AssumeConsole",
        "sts:GetWebIdentityToken",
        "sts:TagGetWebIdentityToken"
      ],
      "Resource": "*"
    }
  ]
}

• sts:GetWebIdentityToken: Claude Console へのフェデレーション時に、web identity token の発行に使われる（出典: IAM policies の Federating to the Claude Console / Outbound web identity federation）
• sts:TagGetWebIdentityToken: capability や workspace context をトークンに載せるために使われる、という整理（同上）

Capability（権限レベル）の話だけメモ

Console 側の権限レベルとして developer / admin などの整理があり、IAM 側では Condition で寄せる、という話も出てきます（細部は公式の Condition キー説明 Actions, resources, and condition keys for Claude Platform on AWS が本家です）。

{
  "Condition": {
    "StringEquals": {
      "aws-external-anthropic:Capability": "developer"
    }
  }
}

マネージドポリシー一覧と使い分け

AWS が用意しているマネージドポリシーは、だいたい次の4つが比較表の出発点になります。

注意点として、公式ドキュメントの整理では AnthropicReadOnlyAccess / AnthropicInferenceAccess / AnthropicLimitedAccess は AssumeConsole を付与しないため、Console のフェデレーションが必要な principal には AnthropicFullAccess か、AssumeConsole（と STS）を明示したカスタムポリシーが必要になります（出典: 同上 IAM policies の Managed policies の Note）。

あと、AnthropicInferenceAccess の Get* / List* はワイルドカードなので、意図せず広く見える、という観点でのレビューもあります（GetFile なども含む、という話）。

Resource に workspace ARN を書くとどうなるか

冒頭の「前提: Workspace は『請求・レート制限・IAM の境界線』」で触れた通り、Workspace は IAM の主要リソースです。ARN の形はだいたい次です。

arn:aws:aws-external-anthropic:<region>:<account-id>:workspace/<workspace-id>

例:

arn:aws:aws-external-anthropic:ap-northeast-1:123456789012:workspace/wrkspc_01AbCdEf23GhIj

単一ワークスペース（= 単一リージョン × 単一論理分離単位）へのアクセス制限に使える、というのがメリットです。環境別・顧客別に Workspace を切っておけば、IAM ロール側で workspace ARN を Resource に書くだけで「このロールは prod Workspace しか叩けない」「customer-a Workspace しか叩けない」が表現できます。

一方で、ListWorkspaces や CreateWorkspace のような アカウントスコープの操作は、workspace ARN を Resource に書いても期待どおりに絞れませんでした。ここは別ステートメントで Resource: "*" を切る、みたいな設計が必要になりがちです。

まとめ: ユースケース別の最小権限チートシート

ここまでの内容を、判断用の一行表に圧縮します。AnthropicAWS や Bearer で推論する場合は、「SigV4とSTSの関係」節の表どおり STS が必須である点も織り込んでください。

「API key を一切発行しないで済む構成」は、Lambda / Claude Code / EC2 の SigV4 側に寄せるほど現実的になりやすいです。Claude Desktop は、短期トークン generator で運用をマシにしつつも、Bearer 経路は IAM 上は残ります。

やってみた（疎通確認）

この記事の本体は IAM の整理ですが、ap-northeast-1 で SigV4 / Console フェデレーション / Bearer token の順に、実際にレスポンスまで確認しました。アカウント固有の値は wrkspc_xxxxxxxxxx のようにマスクしています。IAM に書くべきアクションの言い切りは「SigV4とSTSの関係」節の表を正とし、直前のまとめ表は用途別の索引用です。以下は実験手順と結果だけを示します。

前提（Outbound Web Identity Federation）

前提条件として、アカウントで Outbound web identity federation を有効化しておく必要があります。公式ドキュメントでは、Claude Platform on AWS のゲートウェイが STS を介したトークン発行に関わる、という説明になっています（出典: Prerequisites for using Claude on AWS）。

aws iam enable-outbound-web-identity-federation
aws iam get-outbound-web-identity-federation-info
# JwtVendingEnabled が true なら OK（すでに有効なら enable はエラーになるだけ）

Python SDK は pip install anthropic で、from anthropic import AnthropicAWS が使えます。

実験A: SigV4 経路（Python SDK / curl）

実験で通った IAM（カスタム最小の例）

ワークスペース ARN で細かく切る形もありますが、今回の検証では次の 広めの Resource（*） で SigV4 疎通まで持っていきました。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "aws-external-anthropic:CreateInference",
        "sts:GetWebIdentityToken",
        "sts:TagGetWebIdentityToken"
      ],
      "Resource": "*"
    }
  ]
}

この検証では、CreateInference だけを許可したポリシーでは AnthropicAWS から推論できず、sts:GetWebIdentityToken と sts:TagGetWebIdentityToken を同一ステートメント（または別ステートメント）で追加したときに初めて疎通した（実験用に Resource: "*" の広めの JSON で確認）。つまり AnthropicAWS 経路では、この 2 つの STS アクションを IAM に明示する必要がある。

本番で権限を絞るなら、AnthropicInferenceAccess の JSON のように Condition（sts:IdentityTokenAudience や aws:CalledViaLast など）を付けた STS 許可を真似するのが安全です。

なお Lambda のデフォルトで付与されがちな AWSLambdaBasicExecutionRole だけでは STS は含まれません。AnthropicInferenceAccess をアタッチするか、必要な STS を明示したポリシーを足す必要があります。

A-1: Python SDK（AnthropicAWS）

クライアント名は AnthropicAWS です。AnthropicBedrock ではありません。

import os
from anthropic import AnthropicAWS

os.environ["AWS_REGION"] = "ap-northeast-1"
os.environ["ANTHROPIC_AWS_WORKSPACE_ID"] = "wrkspc_xxxxxxxxxx"

client = AnthropicAWS()
message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=10,
    messages=[{"role": "user", "content": "Hello! Reply in one word."}],
)
print(message.content[0].text)

実行結果（抜粋）:

[SUCCESS] Status: 200
Response: Hello!
Model: claude-sonnet-4-6
Input tokens: 15 / Output tokens: 5

A-2: curl + --aws-sigv4（macOS の curl 8.x 以降）

認証情報は環境変数に載せ、セッショントークンがある場合はヘッダに渡します。

curl "https://aws-external-anthropic.ap-northeast-1.api.aws/v1/messages" \
  --aws-sigv4 "aws:amz:ap-northeast-1:aws-external-anthropic" \
  --user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \
  -H "x-amz-security-token: $AWS_SESSION_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-workspace-id: wrkspc_xxxxxxxxxx" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-4-6","max_tokens":10,"messages":[{"role":"user","content":"Hello! Reply in one word."}]}'

長期アクセスキーでセッショントークンが無い場合は、x-amz-security-token 行を省略して試す形になります。

--aws-sigv4 のサービス名は aws-external-anthropic が正しい形でした。レスポンスは HTTP 200 で、本文に "text": "Hello!" が含まれることを確認しました。

A-3: ネガティブテスト（無効な workspace ID）

意図的に存在しないワークスペース IDを渡すと、次のように 400 で弾かれました。

HTTP Status: 400
Message: anthropic-workspace-id header must be a valid workspace ID.

A-4: Lambda に載せるときのメモ

Lambda で AnthropicAWS を直接使う場合のイメージです。CLAUDE_CODE_USE_ANTHROPIC_AWS=1 は Claude Code CLI 向けなので、Lambda では通常不要です。

import os
from anthropic import AnthropicAWS

def handler(event, context):
    client = AnthropicAWS()
    message = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=100,
        messages=[{"role": "user", "content": "Hello"}],
    )
    return {"statusCode": 200, "body": message.content[0].text}

環境変数は ANTHROPIC_AWS_WORKSPACE_ID と AWS_REGION をセットすれば十分、という整理でした。

実験B: AssumeConsole（Claude Console ログイン）

マネジメントコンソールの「Claude Platform on AWS」から 「サインイン」 を押し、platform.claude.com に遷移できることを確認しました。画面上は developer capability のフェデレーションログインとして入れた状態になっていました。

左サイドバーで「ワークスペースがありません」と出る場合は、Workspace Switcher でワークスペースを選んでいないだけ、というパターンもあり得ます（ログイン自体は成功している状態でした）。

実験C: Bearer token 経路（CallWithBearerToken）

token-generator-for-aws-external-anthropic で IAM 認証情報から短期トークンを作り、anthropic.Anthropic クライアントで叩く経路です。

pip install anthropic token-generator-for-aws-external-anthropic

import boto3
import anthropic
from token_generator_for_aws_external_anthropic import TokenGenerator

REGION = "ap-northeast-1"
WORKSPACE_ID = "wrkspc_xxxxxxxxxx"

session = boto3.Session(region_name=REGION)
generator = TokenGenerator(session=session, region=REGION)
token = generator.get_token()

client = anthropic.Anthropic(
    api_key=token,
    base_url=f"https://aws-external-anthropic.{REGION}.api.aws",
    default_headers={
        "anthropic-version": "2023-06-01",
        "anthropic-workspace-id": WORKSPACE_ID,
    },
)
message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=10,
    messages=[{"role": "user", "content": "Hello! Reply in one word."}],
)
print(message.content[0].text)

Bearer 経路は HTTP 200 で返ってきました。

ネガティブテスト: CallWithBearerToken が無いロール

次のように CallWithBearerToken を付けていないテスト用ロールを用意し、同じ Bearer token で叩くと 403 になりました。

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "aws-external-anthropic:CreateInference",
        "sts:GetWebIdentityToken",
        "sts:TagGetWebIdentityToken"
      ],
      "Resource": "*"
    }
  ]
}

403 Forbidden
aws-external-anthropic:CallWithBearerToken not authorized

比較: 同じロールで SigV4 は通る

同じロールのまま SigV4（AnthropicAWS） に切り替えると、こちらは HTTP 200 でした。

Bearer 経路では CallWithBearerToken が無いと 403 になる。SigV4（AnthropicAWS）経路では CreateInference と STS 2 アクションの 3 つが揃っていないと推論が失敗する（実験A）。どちらの経路も最終的には同一推論 API に届くが、IAM で見える必須アクションの組み合わせが違う。

かかったコストの感触

数回の短い max_tokens=10 程度の呼び出しに留めたので、全体で 1セント未満に収まりました。

ハマりどころまとめ

参考資料

• Prerequisites for using Claude on AWS
• Making requests to Claude on AWS
• IAM policies for Claude on AWS
• Authentication and access control for Claude on AWS
• Claude Code を Claude Platform on AWS に接続して SigV4 認証を試してみた
• Claude Desktop を Claude Platform on AWS に接続してみた

どうぞ参考にしてみてください。