Claude Media
Claude in Amazon Bedrockの認証3経路と長期キーを拒否するIAM
ClaudeClaude連携解説

Claude in Amazon Bedrockの認証3経路と長期キーを拒否するIAM

Claude in Amazon Bedrockのサービスロール・IAM引き受けロール・ベアラートークンの選び分けと、長期キーを拒否するIAMポリシー、既定クォータを確認します。

読了目安 約11分

Claude in Amazon Bedrockの認証経路は3つです。Bedrockサービスロール(推奨)、IAMの引き受けロール、ベアラートークンの順に推奨度が下がります。ベアラートークンは最大12時間の短期トークンに限るのが前提で、長期キーは管理者側のIAMポリシーで使えなくしておくのが安全です。

この記事では、3経路の選び分け、長期キーを拒否するポリシーの書き方、Mantleエンドポイント特有の落とし穴、既定クォータを順に確認します。

Claude in Amazon Bedrockとは何か

Claude in Amazon Bedrockは、AWSが管理するインフラ上でClaudeをMessages API(/anthropic/v1/messages)として提供する形態です。Anthropicの担当者は推論基盤にアクセスできません。エンドポイントはhttps://bedrock-mantle.{region}.api.aws/anthropic/v1/messagesの形で、Anthropic自身のAPIと同じリクエスト本文で呼び出せます。

InvokeModelやConverseを使う従来のBedrock連携は別ページに分かれており、そちらが主題の入り口はAmazon BedrockでClaudeを使うにあります。Claude Code側の設定はClaude Code Bedrock Mantleエンドポイントの使い方が扱っています。

認証3経路をどう選ぶか

くらべる

推奨度の高い順に見る3経路

推奨

サービスロール

AWS管理のキーで長く安定して使える経路です。管理者がBedrockサービスロールを用意し、開発者にiam:PassRoleをそのロールARNに対して付与します。呼び出し時はBedrockがロールを代わりに引き受けます。

ID連携向け

IAM引き受けロール

最大12時間のセッションで使う、IDフェデレーション前提の経路です。信頼ポリシーにSAML・OIDC・AWS Identity Centerのいずれかを指定し、権限ポリシーでbedrock-mantle:CreateInferenceを許可モデルのARNだけに絞ります。

最も非推奨

ベアラートークン

IAMロールを使わない短期アクセスで、最大12時間です。管理者は長期キーを拒否するポリシーを先に付け、開発者はaws-bedrock-token-generatorでトークンを発行します。

選び分けの軸は、誰の権限で、どれだけ長く呼ぶかです。

  • アプリケーションが常時Claudeを呼ぶなら、期限切れの心配が小さいサービスロールが第一候補です。
  • 社員が自分の端末や開発環境から呼ぶなら、会社のIDプロバイダーで認証してロールを引き受ける形が合います。STSが一時的な認証情報を発行し、SDKやCLIがそれで署名します。
  • IAMロールを用意できない短期の検証や、Bearer形式しか受けないクライアントを使うときだけ、ベアラートークンに降ります。

3経路のうちSigV4署名で呼べるのは前の2つです。ベアラートークンは署名ではなくトークンをそのまま渡す形になります。標準のAnthropicクライアントにbase URLをhttps://bedrock-mantle.{region}.api.aws/anthropicとして渡す書き方もありますが、この書き方が受けるのはベアラートークンだけです。SigV4署名が要るときはAnthropicBedrockMantle(C#はAnthropicBedrockMantleClient、Goはbedrock.NewMantleClient)を使います。

SDKが認証情報を拾う順序

Bedrock専用のSDKクラスは、AWS標準の優先順位で認証情報とリージョンを解決します。コンストラクタ引数、環境変数(AWS_ACCESS_KEY_ID・AWS_SECRET_ACCESS_KEY・AWS_SESSION_TOKEN・AWS_REGION)、AWS設定ファイルと認証チェーン(SSO・引き受けロール・ECSタスクロール・IMDS)の順です。引き受けロールで得た一時認証情報は、この環境変数かチェーン経由でそのまま使われます。

Pythonの最小例は次の形です。

pip install -U "anthropic[bedrock]"
from anthropic import AnthropicBedrockMantle
 
client = AnthropicBedrockMantle(aws_region="us-east-1")
 
message = client.messages.create(
    model="anthropic.claude-opus-5-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)

モデルIDにはanthropic.のプレフィックスが付きます。Opus 5.5はanthropic.claude-opus-5-5、Sonnet 5.5はanthropic.claude-sonnet-5-5です。

長期キーを拒否するIAMポリシーを書く

Bedrock APIキーには短期と長期があります。AWSの説明では、短期キーは12時間とキーを発行したセッションの長さのうち短い方まで有効で、発行元プリンシパルの権限を引き継ぎ、発行したリージョンでしか使えません。長期キーは探索用途に限る推奨で、発行するとIAMユーザーが裏で作られ、有効期限は発行時に決められます。

ここで効くのが、キーの使用を制御する条件キーです。使用はエンドポイントごとの別々のIAMアクションで制御され、Bedrockエンドポイントはbedrock:CallWithBearerToken、Mantleエンドポイントはbedrock-mantle:CallWithBearerTokenです。キー経由のアクセスを完全に止めるには両方を拒否する必要があります。それぞれにbearerTokenType条件キーがあり、値はSHORT_TERMかLONG_TERMです。

次のポリシーは、長期キーでの利用を両エンドポイントで拒否します。例えば次のような形になります(AWSの例に沿った形)。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "bedrock:CallWithBearerToken",
      "Resource": "*",
      "Condition": {
        "StringEquals": { "bedrock:bearerTokenType": "LONG_TERM" }
      }
    },
    {
      "Effect": "Deny",
      "Action": "bedrock-mantle:CallWithBearerToken",
      "Resource": "*",
      "Condition": {
        "StringEquals": { "bedrock-mantle:bearerTokenType": "LONG_TERM" }
      }
    }
  ]
}

Anthropicのページには「bedrock:CallWithBearerTokenを、bedrock:BearerTokenType条件が短期トークンに一致しない限り拒否する」という趣旨の手順があります。この文面と上のAWS側の例には、見落としやすい差が2つあります。

注意点

ポリシーを書く前に確かめる点

  • Mantleのアクションも拒否する

    Anthropicの手順が名指しするのはbedrock:CallWithBearerTokenだけです。Claude in Amazon BedrockはMantleエンドポイントなので、bedrock-mantle:CallWithBearerTokenも同じ条件で拒否しないと、Mantle経由では長期キーが通る可能性が残ります。

  • 条件キーの綴り

    AWSのポリシー例ではbearerTokenTypeの先頭が小文字です。AnthropicのページはBearerTokenTypeと書いているので、貼る前にAWSの例の綴りに合わせてください。

  • 短期キーの発行は止められない

    短期キーは既存セッションの認証情報から作られるため、AWSの警告どおり発行そのものは防げません。止められるのは使用です。

発行を止めるか、使用を止めるか

長期キーの発行側と使用側は、別の仕組みで制御します。

目的長期キー短期キー
発行を防ぐ長期キーiam:CreateServiceSpecificCredentialを拒否短期キー防げない
使用を防ぐ長期キーキーに紐づくIAMユーザーなどにCallWithBearerTokenの拒否を付ける短期キーキーを発行した主体にCallWithBearerTokenの拒否を付ける

発行側は、条件キーiam:ServiceSpecificCredentialAgeDaysで有効期限が90日以内のキーだけ作れるようにしたり、iam:ServiceSpecificCredentialServiceNameでBedrock向けに限定したりもできます。長期キーを全社で禁止するなら、発行の拒否と使用の拒否を両方付けるのが組み合わせとして素直です。

ベアラートークンの発行と渡し方

短期トークンはaws-bedrock-token-generatorライブラリで発行できます。長時間動くアプリケーションでは、認証情報の更新に合わせて新しい短期キーを作る自動更新の設定も用意されています。

渡し方は、環境変数AWS_BEARER_TOKEN_BEDROCKにキーを設定するか、リクエストに含めるかです。ヘッダーの書式は、Anthropicのページではx-api-key、Bedrock APIキーを説明するAWSのページではAuthorization: Bearer $AWS_BEARER_TOKEN_BEDROCKと書かれており、ページごとに表記が違います。SDKを使えばヘッダーの違いは意識しなくて済むので、直接HTTPを組むときだけ、呼ぶエンドポイントの手順に従って確認してください。Claude Code側の環境変数の挙動はAWS_BEARER_TOKEN_BEDROCKとはにまとめています。

既定クォータと申請の目安

既定の上限は入力トークン毎分(TPM)で200万です。Anthropicへの追加承認なしで、入力500万TPMと出力50万TPMまで引き上げを申請できます。リクエスト毎分(RPM)の上限はBedrock側でAWSが管理するため、調整はAWSサポートに依頼します。

経路の選択とは別に、本番投入前に引き上げ申請が要るかを見積もっておくと安全です。

認証以外で先に確認したい制約

認証を通しても、使えない機能があります。構造化出力、URL指定の画像・文書入力とFiles API、コード実行・Web検索などのサーバー側ツール、Agent SkillsやMCPコネクタ、Message Batches、Claude Managed Agentsは、Claude in Amazon Bedrockでは非対応です。サーバー側のフォールバック(fallbacksパラメータ)も使えず、クライアント側のフォールバックで代替します。プロンプトキャッシュ、拡張思考、ツール使用、引用は対応しています。

リージョンには、全リージョン共通のGlobalと、データ所在要件向けのRegionalの2種類があります。Regionalは直接APIより10%高い料金が付きます。東京リージョンの扱いはAmazon Bedrock東京リージョンでClaudeを使うに詳しく、Claude Code側のIAM権限の組み方はClaude Code Bedrock IAM設定で扱っています。

データの取り扱いはAmazon Bedrockの規定に従い、ログはCloudWatchとCloudTrailに出ます。Anthropicは活動ログを少なくとも30日のローリングで保持することを勧めています。サポートの窓口は専用のメールアドレスで、AWSアカウントIDと失敗したレスポンスのrequest-idを添えて連絡します。

運用に落とすときの順序

  1. 開発者全員のベースに、サービスロール経由の経路を用意する
  2. 長期キーの使用拒否ポリシーを、bedrock:とbedrock-mantle:の両方で組織に付ける
  3. IDプロバイダー連携で引き受けロールを使う人を決める
  4. ベアラートークンは例外申請として扱い、発行元の主体を限定する
  5. 本番前に入力TPMの引き上げ要否を決める

この順にすると、最も安全な経路が標準になり、ベアラートークンは例外として残るだけになります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude をもっと見る →