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

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

AWS authentication failedは、AWSプロバイダーが403を返したとき、またはAmazon Bedrockが401を返したときに表示されます。表示条件は同系統のエラー「AWS credentials expired or invalid」と同じです。Claude Code v2.1.198以降かつ設定ファイルにawsAuthRefreshが設定されているときだけ出ます。

このエラーの厄介な点は、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 ...

中央のヒント部分は、設定ファイルのawsAuthRefreshコマンドを反映して変わります。固定なのは先頭のAWS authentication failedだけです。メッセージ自体が「まずリフレッシュを試し、それでも直らなければ権限を確認してください」という2段構えの案内になっているのは、原因を1つに絞れない設計を反映した結果です。上から順に試すだけで、多くのケースは自然に切り分けられます。

なぜ403だけで原因が判別できないのか

Amazon Bedrockが返す403には、次の2つの意味が混在します。

• 期限切れのセキュリティトークン(本来はAWS credentials expired or invalidが扱う401のケースに近い状態)
• IAM権限そのものの不足。bedrock:InvokeModel権限が付与されていない、またはそのモデルがアカウントで有効化されていない場合のAccessDeniedException

401についても事情が違います。Amazon Bedrockは期限切れトークンを401として報告しないため、Bedrockから401が返ってきた場合はこのエラーの対象になります。ただしその原因は、たいてい期限切れとは別のところにあります。多くは企業のプロキシなど、リクエスト経路の途中にある別要因です。

切り分け手順

原因を絞り込むには、次の順で確認します。

aws sts get-caller-identity

1. まずawsAuthRefreshに設定したコマンド(aws sso login --profile myprofileなど)を別ターミナルで実行し、リトライする。これでトークン失効のケースは解消します
2. リフレッシュしても直らない場合、上のコマンドでリクエストがどの身元を使っているか確認する。想定と違うプロファイルが使われていないかをここで見つけられます
3. 身元が正しければ、そのIAMロールやユーザーにbedrock:InvokeModel・bedrock:InvokeModelWithResponseStream権限が付いているかを確認する。あわせて、対象のモデルがそのアカウント・リージョンで有効化されているかも見る

この3段階は、上から順に切り分けの網を絞り込む構成になっています。1で直ればトークン失効、2で身元がズレていれば設定ミス、3まで進んでようやくIAM権限そのものの見直しに入る、という流れです。いきなり3から手を付けると、実は1で直る単純な失効だったケースを見落とします。

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

Amazon Bedrock経由でこのエラーに当たった場合、確認すべき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/*"
      ]
    }
  ]
}

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

Mantleエンドポイントを使っている場合は、もう1つ別の403パターンがあります。認証情報自体は有効なのに、AWSアカウントがそのモデルへのアクセスを許可されていないケースです。この場合はIAMポリシーの見直しではなく、AWSのアカウント担当チームへモデルアクセスの許可を依頼する話になります。

Claude Platform on AWSの403は単純

同じ403でも、Claude Platform on AWS経由の場合は原因がやや絞りやすくなります。IAMプリンシパルが、Anthropicのサービスを呼び出すaws-external-anthropic系のアクションを持っていないことが典型的な原因です。

もう1つ見落としやすいケースがあります。ANTHROPIC_AWS_API_KEYを設定している場合、このキーはSigV4より優先されるため、キーが失効していると同じ403になります。この場合はAWSコンソールのClaude Platform on AWS → API keysでキーを再発行するか、環境変数を外してAWS認証情報側にフォールバックさせます。

403と混同しやすい別のエラーもあります。ANTHROPIC_AWS_WORKSPACE_IDが未設定、または空の場合に出る「ワークスペースが見つからない」というエラーです。Claude Platform on AWSのリクエストは必ずワークスペースIDを含む必要があり、AWSの認証情報だけからは推測できません。403とは原因も対処もまったく別なので、AWS authentication failedと表示されていないのにリクエストが失敗する場合は、まずこのIDが正しく設定されているかを疑います。

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

トークンの失効だけが原因だとほぼ確定しているケースは、AWS credentials expired or invalidの直し方で扱う401です。一方、本記事のAWS authentication failedは、リフレッシュだけでは解決しない可能性がある点が違います。

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

Bedrock経由の料金や、Claude Platform on AWSとの契約形態の違いをあわせて確認したい場合はAWS BedrockのClaude料金は直接APIとどう違うかも参考になります。ログイン方式そのものの優先順位はClaude Codeログイン方法3種の使い分けにまとめています。

よくある質問

認証情報が最新なのに403が出ます。何を疑えばいいですか

トークンの失効ではなくIAM権限側を疑います。対象のIAMロールにbedrock:InvokeModelとbedrock:InvokeModelWithResponseStreamが付与されているかを確認します。あわせて、呼び出そうとしているモデルがそのアカウント・リージョンで有効化されているかも見ます。

自分がAWS認証情報とAPIキーのどちらでリクエストしているか、どこで判別しますか

/statusを実行すると、現在使われている解決済みのプロバイダーが表示されます。ANTHROPIC_AWS_API_KEYが環境に残っていると気づかないまま優先され続けることがあるため、心当たりのない403に当たったら、まずここでどちらの認証経路が使われているかを確認するのが近道です。

401はどんなときに出ますか

Amazon Bedrockは期限切れトークンを401として報告しないため、Bedrockからの401はたいてい別の要因です。企業プロキシなど、リクエスト経路の途中にある要因を疑う必要があります。

Mantleエンドポイント経由で403が出た場合も同じ手順で直りますか

原因によります。認証情報自体が正しいのにMantleから403が返る場合は、IAM権限の不足ではなくAWSアカウントがそのモデルへのアクセスを許可されていないことが典型的な原因です。この場合はポリシーを見直すのではなく、AWSのアカウント担当チームへモデルアクセスの許可を依頼します。

「ワークスペースが見つからない」というエラーとは別物ですか

別物です。ANTHROPIC_AWS_WORKSPACE_IDが未設定・空のときに出るエラーで、AWS authentication failedとは表示も原因も異なります。Claude Platform on AWSのリクエストには必ずワークスペースIDが必要なので、このエラーが出た場合はIAM権限ではなく環境変数の設定漏れを疑います。

aws sts get-caller-identityで何が分かりますか

実際のリクエストがどのIAM身元を使っているかが分かります。古いAWS_PROFILEやデフォルトプロファイルが残っていて、想定と違う権限のロールが使われている、という不一致の発見によく使います。原因の切り分けを始める前に、まずこのコマンドで身元を固定しておくと後の手順が早く進みます。

まとめ

AWS authentication failedは、トークン失効とIAM権限不足のどちらでも表示される403(Bedrockの場合は401もあり得る)です。まずawsAuthRefreshのコマンドでリトライし、それでも直らなければaws sts get-caller-identityで身元を確認したうえでIAM権限とモデルの有効化状況を見直します。Claude Platform on AWS経由ならaws-external-anthropic系の権限、あるいはANTHROPIC_AWS_API_KEYの失効も見落としやすいポイントです。リフレッシュだけで直るかどうかが、トークン側の問題か権限側の問題かを見分ける最初の判断材料になります。

Mantleエンドポイント特有の「アクセス未許可」や、ワークスペースID未設定によるまったく別のエラーとの混同にも注意します。メッセージの先頭が同じAWS authentication failedかどうかを最初に確認する習慣をつけておくと、原因の異なるエラーを同じ手順で追いかけてしまう遠回りを避けられます。