Claude Media
AWS authentication failedの原因と対処 — Claude CodeでAWS認証を切り分ける
Claude CodeTips

AWS authentication failedの原因と対処 — Claude CodeでAWS認証を切り分ける

「AWS authentication failed」はトークン失効とIAM権限不足のどちらでも出る403/401です。原因の切り分け手順をまとめます。

読了目安 約12分

「AWS authentication failed」は原因を1つに絞れないエラー

AWS authentication failedは、AWSプロバイダーが403を返したとき、またはAmazon Bedrockが401を返したときに表示されます。同系統のAWS credentials expired or invalidと同じく、v2.1.273より前はawsAuthRefreshが設定されているときにしか出ませんでした。v2.1.273以降は設定の有無に関係なく出ます。

Claude Code自身が、原因を1つに絞り込めません。Amazon Bedrockは期限切れのセキュリティトークンを403で報告します。しかし同じ403は、IAM権限不足による認可拒否(AccessDeniedException)でも返ります。トークンが古いのか、権限が足りないのかを、この文面だけから判定する方法はありません。

メッセージの読み方

実際の表示は次のような形です。

AWS authentication failed · run /login and select "Claude Platform on AWS · refresh credentials", or run `aws sso login --profile myprofile` in another terminal · if credentials are current, check AWS permissions and model access · API Error: 403 ...

中央のヒント部分は、設定に応じて変わります。固定なのは先頭のAWS authentication failedだけです。

モデル指定の誤りは、ヒントの文面で見分けられます。Amazon Bedrockが「指定したモデルIDへのアクセス権がない」という趣旨の403を返すことがあります。このときヒントはAmazon Bedrockコンソールで対象のアカウント・リージョンのモデルを有効化するよう案内する文面に変わります。ヒントが「認証情報はこの環境が管理している」という趣旨のときは、Claude Codeを起動したアプリが認証情報を持っています。その場合は再試行するか、管理者に問い合わせます。

403と401は別の経路で切り分ける

401は、Amazon Bedrockが期限切れトークンを401で報告しない点が手がかりです。Bedrockから401が返ってきた場合、原因は期限切れではなく、企業のプロキシなどリクエスト経路の途中にあるものが典型です。トークンを更新し直しても直りません。

403は3つの経路で意味が違います。どのエンドポイントに向けているかを先に確定すると、見るべきIAMの名前空間が決まります。

403の読み分け

経路ごとの403の典型原因

  • Bedrock Invokeエンドポイント

    期限切れトークンか、bedrock:InvokeModel系の権限不足です。モデルが対象アカウント・リージョンで有効でない場合もここに入ります。

  • Mantleエンドポイント

    権限の名前空間がbedrock-mantle:で、Invokeのbedrock:とは別です。エラーがbedrock-mantle:のアクション名を挙げていれば、そのアクションを付与します。

  • Claude Platform on AWS

    aws-external-anthropic系のIAMアクション不足か、失効したANTHROPIC_AWS_API_KEYが原因です。

切り分け手順

トークン失効か権限不足かは、次の順で確認します。

aws sts get-caller-identity
手順

403を切り分ける順序

  1. 1

    リフレッシュして再実行する

    awsAuthRefreshに設定したコマンド(aws sso login --profile myprofileなど)を別ターミナルで実行し、リトライします。これで直れば、トークン失効が原因でした。awsAuthRefreshを設定していない場合は、使っている認証情報(SSOサインイン、アクセスキー、APIキー、プロキシのトークン)を自分で更新してからリトライします。

  2. 2

    使われている身元を確かめる

    上のコマンドを、Claude Codeを起動するのと同じシェル・同じプロファイルで実行します。想定と違うプロファイルが使われていないかをここで見つけられます。

  3. 3

    権限とモデルの有効化を見る

    身元が正しければ、そのIAMロールやユーザーに権限が付いているかを確認します。対象のモデルがそのアカウント・リージョンで有効かどうかも見ます。

awsAuthRefreshには、手順1の結果の読み方を左右する仕様があります。このコマンドは、Claude Codeが認証情報の期限切れを検知したときにだけ動きます。実行前にはSTSのGetCallerIdentityを呼び、認証情報がまだ使えるとわかればコマンドを実行しません。IAM権限の不足が原因の403では、Claude Codeが自動でリフレッシュを走らせない可能性があるということです。手順1では、自動実行を待たず自分でコマンドを実行します。

このSTS確認はHTTPS_PROXYとNO_PROXYを尊重してプロキシ経由で送られます。v2.1.239より前は直接送っていたため、外向き通信をプロキシに限る環境では起動時に固まっていました。awsAuthRefreshを使わずawsCredentialExportだけを設定した場合は、エクスポートされた認証情報がそのまま使われ、起動時にAWSの既定の認証情報チェーンは再解決されません(v2.1.206以降)。

IAM権限を具体的に確認する

Amazon Bedrock(Invokeエンドポイント)経由で確認すべきIAMポリシーの骨格は次のとおりです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowModelAndInferenceProfileAccess",
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:ListInferenceProfiles",
        "bedrock:GetInferenceProfile"
      ],
      "Resource": [
        "arn:aws:bedrock:*:*:inference-profile/*",
        "arn:aws:bedrock:*:*:application-inference-profile/*",
        "arn:aws:bedrock:*:*:foundation-model/*"
      ]
    }
  ]
}

公式のポリシー例には、このStatementの後にもう1つAllowMarketplaceSubscriptionがあります。aws-marketplace:ViewSubscriptionsとaws-marketplace:Subscribeを、呼び出し元がbedrock.amazonaws.comのときに限って許可するものです。ポリシーを自前で組むときは、この文の写し漏れも確認します。

Resourceを絞りたいときは、特定の推論プロファイルのARNに限定できます。

bedrock:InvokeModelとbedrock:InvokeModelWithResponseStreamが無いと、リクエストそのものが403で弾かれます。bedrock:GetInferenceProfileは性質が違います。欠けていてもClaude Codeは代替の形式で1回リトライして成功させます。ただし新しいモデルへ切り替えるたびに、余分な往復が1回発生します。ポリシーが絞られがちなAWS_BEARER_TOKEN_BEDROCKの構成では、この権限を含めておくとリトライが不要です。

Mantleでは権限の名前が変わる

Mantleは同じAWS認証情報とawsAuthRefreshの設定を使いますが、IAMアクションはbedrock-mantle:の別系統です。上のbedrock:のポリシーはカバーしません。推論にはbedrock-mantle:CreateInference、トークンのカウントにはbedrock-mantle:CountTokensを付与します。

Mantleの403は、エラーがIAMアクション名を挙げているかどうかで分かれます。

  • アクション名を挙げている場合は、そのアクションをIAMの身元に付与します
  • 名前を挙げておらず認証情報が有効な場合は、AWSアカウントがそのモデルへのアクセスを許可されていません。AWSのアカウント担当チームへ、アクセス許可を依頼します

まず疑うのは環境変数の届き方です。CLAUDE_CODE_USE_MANTLEを設定しても/statusにAmazon Bedrock (Mantle)が出なければ、変数がプロセスに届いていません。403以前の問題です。

Mantleでは、モデルIDの形式違いによる400もあります。us.anthropic.claude-sonnet-4-6のような推論プロファイルIDは、Mantleでは使えません。anthropic.claude-sonnet-5のようなMantle形式のIDを使います。

Claude Platform on AWSの403は、認証の優先順位で切り分ける

Claude Platform on AWS経由の403は、IAMプリンシパルにaws-external-anthropic系のアクションが無いことが典型的な原因です。もう1つ見落としやすいのが、キーの優先順位です。ANTHROPIC_AWS_API_KEYを設定していると、このキーはx-api-keyとして送られ、SigV4より優先されます。環境にあるAWS認証情報は無視され、キーが失効していれば同じ403になります。

対処は2通りです。AWSコンソールのClaude Platform on AWS → API keysでキーを再発行するか、環境変数を外してAWS認証情報側にフォールバックさせます。別のClaude Consoleの組織で発行したキーは使えません。AWS Marketplaceの契約で作られる組織は、すでに持っている組織とは別だからです。

403と混同しやすい別のエラーもあります。ANTHROPIC_AWS_WORKSPACE_IDが未設定または空だと、ワークスペースが見つからない趣旨のエラーが出ます。このIDはリクエストごとに必要で、AWSの認証情報からは推測できません。AWS authentication failedと表示されないのに失敗する場合は、まずこのIDを疑います。

プロバイダーが意図したものになっているかは、/statusのAPI provider行で確認できます。CLAUDE_CODE_USE_BEDROCKやCLAUDE_CODE_USE_FOUNDRYが同時に設定されていると、それらがClaude Platform on AWSより優先されます。Claude Platform on AWSのつもりでBedrockに向いている場合、Bedrock側のIAMを直しても403は消えません。

「AWS credentials expired or invalid」との使い分け

トークンの失効だけが原因だとほぼ確定しているケースは、AWS credentials expired or invalidの直し方で扱う401です。こちらはClaude Platform on AWSまたはMantleが401を返したときに出ます。一方AWS authentication failedは、リフレッシュだけでは解決しない可能性がある点が違います。

判断の目安は、リフレッシュコマンドを実行したあとの挙動です。直るならトークン失効側、同じエラーが返るなら、権限設定そのものに問題が残っている可能性が高くなります。awsAuthRefreshの追加方法や、社内プロキシでの認証ループといった周辺の落とし穴は、そちらの記事にまとめています。

Bedrock経由の料金や、Claude Platform on AWSとの契約形態の違いはAWS BedrockのClaude料金は直接APIとどう違うかが扱っています。ログイン方式そのものの優先順位はClaude Codeログイン方法3種の使い分けにまとめています。

まとめ

リフレッシュコマンドで直るならトークン失効、直らないならaws sts get-caller-identityで身元を固定し、その身元に経路ごとのIAM権限があるかを見ます。Bedrockのbedrock:、Mantleのbedrock-mantle:、Claude Platform on AWSのaws-external-anthropicと、名前空間が違う点が最も多い取り違えです。

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

関連する記事

Claude Code をもっと見る →