InvalidSignatureException: Signature expired

TL;DR — 署名済みの AWS リクエストは、署名に焼き込まれたタイムスタンプから約5分以内にサービスに到達する必要があります。このエラーは、マシンのクロックが AWS サーバー時刻から遠すぎる(クロックスキュー)ため、署名が「期限切れ」または「まだ有効でない」ことを意味します。クライアントのクロックを修正してください。NTP 時刻同期を有効にします。

意味

InvalidSignatureException: Signature expired: 20260712T101500Z is now earlier
than 20260712T101700Z (20260712T102200Z - 5 min.)

Signature Version 4 は各リクエストをタイムスタンプとともに署名します。AWS はそのタイムスタンプを自身のクロックに対して検証し、およそ 5分 のウィンドウ外のものを拒否します。Signature expired(クライアントクロックが遅れている)または Signature not yet current(クライアントクロックが進んでいる)のいずれかです。これは HTTP 400、クライアント側の問題です。やみくもな再試行は、クロックが修正されるまで再び失敗します。

発生する理由

  • クライアントクロックのドリフト — アプリを実行するホストのクロックが不正確(VM の一時停止/再開、時刻同期のないコンテナ、IoT/エッジデバイス、CI ランナー)。
  • NTP が動作していない — OS クロックを規律する何もないため、5分の許容範囲を超えてゆっくりドリフトする。
  • 手作りのサイナーでの 誤ったタイムゾーン/UTC の扱い — リクエストのタイムスタンプを誤計算する。
  • 長時間サスペンドされたプロセス — 長い停止の後に古い時刻感覚で再開したラップトップや Lambda スタイルの環境。

修正方法

  1. ホストで NTP 時刻同期を有効にしchrony/systemd-timesyncd/w32time)、クロックが実際の UTC の1秒以内であることを確認します。
  2. クロックを比較します: クライアントの UTC 時刻を信頼できるソースと照合します。数分ずれていれば、それが原因です。
  3. VM の再開やコンテナ起動の後に 時刻同期サービスを再起動します(または手動で再同期)。
  4. AWS SDK をアップグレードします — 最新の SDK はクロックスキューエラーを検出し、修正されたオフセットで自動的に再試行します。古い SDK はそうしないかもしれません。

タイムスタンプとスキュー時のリトライ処理を代わりに行ってもらうため、手書きの SigV4 サイナーより公式の AWS SDK を優先してください。

DynoTable で

DynoTable は署名を AWS SDK に任せており、最近のビルドにはクロックスキューの補正が 含まれています(AWS アカウントに接続する)。DynoTable では問題なく 接続できるのに、独自スクリプトだけでこのエラーが出るなら、問題はそのクライアントの時計か サイナーに限られています — Settings → Profiles のプロファイルで Test Connection を 実行して比べてみてください。CI ランナーやスリープする VM では、アプリやテストを走らせる前に NTP を有効にしましょう。

最近の AWS SDK はクロックスキューのエラーを検出し、補正したオフセットでリトライします。 手組みのサイナーでしかこれが起きないなら、DynamoDB 自体を疑う前に SDK を更新するか、 ホストで NTP を有効にしてください。DynoTable は SDK の経路だけを使い、SigV4 を独自に 組み立てることはありません。時計とプロファイルが揃えば読み取りが成功することは、 クエリビルダーで確認できます。

関連するエラー

出典

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

Console なしで DynamoDB を扱う

DynamoDB では実行できない本物の SQL(JOINs、GROUP BY、集計)を実行する高速な DynamoDB デスクトップクライアント。ビジュアル編集と、あなた自身の Bedrock キーで動く AI エージェントを備えています。

30日間無料トライアル、クレジットカード不要 — その後は期限のない Free プラン。