The security token included in the request is invalid

TL;DR — AWS の認証情報が誤っているか、期限切れか、SDK があなたの思っているのとは別の組を読んでいます。アクセスキーとシークレット（一時認証情報ならセッショントークンも）を更新・確認し、SDK が実際にどのプロファイル/ソースを使っているか確かめてください。

意味

UnrecognizedClientException: The security token included in the request is invalid.

AWS は権限を確認する前の認証段階で、あなたの認証情報を拒否しました。これは AccessDeniedException とは異なります。あちらは認証情報が有効だが権限がないことを意味します。ここでは認証情報そのものが受け入れられていません。例外名はツールによって変わります。AWS CLI は同じメッセージを InvalidClientTokenId の下に表示し、DynamoDB のエラーリファレンスは UnrecognizedClientException の項目を「The Access Key ID or security token is invalid.」と表現します — いずれも認証の失敗を意味します。

発生する理由

一時認証情報の期限切れ — STS/SSO のセッションや引き受けたロールのトークンがタイムアウトした、あるいは必要な AWS_SESSION_TOKEN なしでアクセスキーを持っている。
誤ったキー、または不完全なキー — タイプミス、ローテーション/削除されたアクセスキー、対応する AWS_SECRET_ACCESS_KEY なしで設定された AWS_ACCESS_KEY_ID など。
古い AWS_SESSION_TOKEN が前のセッションから環境に残っている。
実際の認証情報を DynamoDB Local に向けている（またはその逆） — Local はどんなダミーキーも受け入れますが、実際のエンドポイントはプレースホルダーを受け入れません。
リクエストの署名を無効にするほど大きい、マシンの 時計のずれ。

修正方法

認証情報が機能するか確認します: aws sts get-caller-identity。これも失敗するなら、問題は DynamoDB ではなく認証情報です。
一時認証情報を更新します — aws sso login を再実行するかロールを引き受け直し、一時キーには AWS_SESSION_TOKEN が設定されていることを確認します。
古い環境変数をクリアします — シェルに残った古い AWS_SESSION_TOKEN/AWS_ACCESS_KEY_ID はプロファイルを上書きします。それらを unset するか、正しいプロファイルを設定してください（aws configure list でどのソースが勝っているか分かります）。

DynamoDB Local では、プレースホルダーの認証情報を使い、ローカルのエンドポイントを指します:

const client = new DynamoDBClient({
  region: 'local',
  endpoint: 'http://localhost:8000',
  credentials: {accessKeyId: 'local', secretAccessKey: 'local'}
});

ほかがすべて正しく見えるなら、マシンの時計 が正確（NTP 同期済み）か確認します。

DynoTable で閲覧していますか？ DynoTable は接続のたびに ~/.aws のプロファイルを新しく解決するので、再ログインやキーのローテーションが再起動なしで反映されます。

DynoTable から

DynoTable は接続のたびに ~/.aws のプロファイルを新しく解決します。そのため、再ログイン、キーのローテーション、環境変数のクリアは、アプリを再起動しなくても拾われます。⌘P を押せば、どのプロファイルが有効か、認証情報のドットが緑かどうかが分かります — 赤いドットは、テーブルへの呼び出しが成功する前に Sign in（SSO）か Reconnect が必要という意味です。DynamoDB Local では、エンドポイント http://localhost:8000 と英数字のプレースホルダーキーでプロファイルを追加してください（DynamoDB Local を動かすを参照）。本物の AWS のキーを Local に使うと、同じエラーが出ます。

よくある質問

「The security token included in the request is invalid」はどういう意味ですか？ AWS が権限を確認する前の認証段階で、あなたの認証情報を拒否しました。キーが誤っている、ローテーションされた、不完全である、一時セッショントークンが期限切れか古い、あるいは SDK が思っているのとは別の認証情報ソースを読んでいます。

無効なセキュリティトークンをデバッグするには？ aws sts get-caller-identity を実行します — これも失敗するなら、問題は DynamoDB ではなく認証情報です。一時認証情報を更新し（aws sso login またはロールの引き受け直し）、一時キーには AWS_SESSION_TOKEN が設定されていることを確認し、プロファイルを上書きする古い環境変数をクリアしてください。

再現方法

これには有効な認証情報もローカルのエンジンも不要です。認可の前に認証が失敗するので、実稼働の DynamoDB サービス が意図的にでたらめなキーに答えてくれます。

import boto3
boto3.client(
    'dynamodb',
    region_name='us-east-1',
    aws_access_key_id='AKIAIOSFODNN7EXAMPLE',
    aws_secret_access_key='wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY',
).list_tables()

実際の出力:

UnrecognizedClientException: The security token included in the request is invalid. [HTTP 400]

構造的に不正な形式のキー（not-a-key）でも同一のメッセージが返ります。そこが実務上の罠です。このエラーは認証情報が拒否されたことは教えてくれますが、なぜかは決して教えてくれません。タイプミス、削除されたアクセスキー、別アカウントのキー、そもそも存在しなかったキーが、すべてここに同じ形で着地します。自分を区別してくれる security token expired と比べてみてください。それと、この対応関係にも注意を。ワイヤ上のコードは UnrecognizedClientException なのに、メッセージは「security token」の話をします — つまりメッセージを検索するのと、ハンドラでクラス名を grep するのとでは、別々の文字列が必要です。

出典

最終検証日 2026-07-13、上記にリンクした公式 AWS ドキュメントに照らして確認しました。

2026-07-26 に us-east-1 の実稼働 DynamoDB サービスに対し boto3 1.43.56 で再現しました — 上記の出力はそのままの逐語です。