DynoTable

DynamoDB IncompleteSignatureException

TL;DR — リクエストの AWS Signature Version 4 の署名が不完全か、AWS の標準に適合していなかったため、DynamoDB は認証前にそれを拒否しました。AWS SDK を使っていれば署名は自動なので、これはほぼ必ず、手で組み立てたリクエストか、署名後に Authorization ヘッダーを壊したプロキシ/ゲートウェイを意味します。署名は SDK に任せ、転送中に何もリクエストを書き換えないようにしてください。

意味

IncompleteSignatureException: The request signature does not conform to AWS standards.

AWS はすべてのリクエストに SigV4 で署名します。この例外は、署名は存在したものの 不正な形式か、必要な構成要素が欠けていた ことを意味します — 壊れた Authorization ヘッダー、欠けた署名対象ヘッダー、あるいは正規リクエストの不一致です。HTTP 400 のクライアント側エラーで、そのままでは リトライ不可 です。署名を直すしかありません。

発生する理由

  • 自前の署名処理 — SigV4 の署名を（SDK を通さず）自分で組み立てていて、正規リクエスト、署名対象ヘッダーのリスト、Authorization ヘッダーのいずれかが誤っている。
  • 不正な形式の Authorization ヘッダー — ドキュメントに挙がっているきっかけは、空のヘッダー、Credential または Signature パラメータの欠落、アルゴリズム名（AWS4-HMAC-SHA256）で始まらないヘッダー、等号のない key=value ペアです。
  • プロキシや API ゲートウェイがリクエストを書き換えた — SDK が署名した後に Authorization ヘッダー（やその他の署名対象部分）を変更すると、AWS が受け取るヘッダーが送信したものと食い違います。
  • 手動で編集されたヘッダー — 署名後のヘッダー追加/削除や、クエリ文字列の並べ替えは、正規リクエストを壊します。

修正方法

  1. 公式の AWS SDK を使い、リクエストの署名を任せます。SDK は SigV4 を正しく実装しています — ほとんどすべてのケースで、修正とは自前署名をやめることです。
  2. 署名後にリクエストを変更しないでください — 前段にプロキシ/ゲートウェイがあるなら、ヘッダーの追加・削除・並べ替えや、ボディ/パスの変更をしないことを確認します。実際に送信するエッジで署名しましょう。
  3. Authorization ヘッダーが転送中に変わったか確認します — AWS がドキュメント化している診断方法です。送ったヘッダーの SHA-256 ハッシュを計算して Base64 エンコードし、一部の IncompleteSignatureException のメッセージに含まれるハッシュと比較します。異なれば、クライアントと AWS の間の何かがヘッダーを改変しています。
  4. どうしても手動で署名するなら、AWS の SigV4 署名プロセスを正確に踏襲します — 正規リクエスト、署名対象文字列、署名キーの導出、Authorization ヘッダー（アルゴリズム、Credential=、SignedHeaders=、Signature=）のすべてが一致しなければなりません。正しく動く SDK のリクエストと突き合わせて検証してください。

誤った、あるいは切り詰められたシークレットキーは別の失敗です。それは 完全な 署名が一致しないという結果を生み、このエラーではなく 「signature we calculated does not match」 として表面化します。同様に、マシンの時計のずれは不完全な署名ではなく Signature expired として現れます。

DynoTable + Local

DynoTable は AWS SDK の署名パスを使い、SigV4 を手組みしません。そのため、通常の利用でこの種のエラーが出ることはありません。DynoTable は動くのにアプリだけがこのエラーに当たるなら、プロファイルを比べてください。Settings → Profiles で、アプリが読み込んでいるのと同じキーを設定して Test Connection を実行します。

Local なら、エンドポイント http://localhost:8000 のプロファイルにダミーの認証情報を設定すれば、署名そのものを回避できます。AWS に接続するとインストールを参照してください。認証情報が解決できたら、クエリビルダーでスモークテストのクエリを実行しましょう。

出典

よくある質問

IncompleteSignatureException は何が原因ですか？ リクエストの AWS SigV4 署名が不正な形式だったか、必要な部分を欠いていました — 空または不正な形式の Authorization ヘッダー、Credential または Signature パラメータの欠落、等号のない key=value ペアなどです。AWS SDK を使えば署名は自動なので、通常は手で組み立てた署名か、署名後にリクエストを改変したプロキシを意味します。

UnrecognizedClientException とはどう違いますか？ IncompleteSignatureException は署名そのものが不正な形式だったことを意味します。UnrecognizedClientException（「security token is invalid」）は、署名は正しい形式だったが、その背後の認証情報が受け入れられなかったことを意味します。

再現方法

存在はするが SigV4 として解析できない Authorization ヘッダーを送ります。

import requests
requests.post(
    'https://dynamodb.us-east-1.amazonaws.com',
    headers={
        'X-Amz-Target': 'DynamoDB_20120810.ListTables',
        'Content-Type': 'application/x-amz-json-1.0',
        'Authorization': 'AWS4-HMAC-SHA256 this-is-not-a-valid-credential-scope',
    },
    data='{}',
)

実際の出力:

IncompleteSignatureException: Invalid key=value pair (missing equal-sign) in Authorization header (hashed with SHA-256 and encoded with Base64): 'nmoNS1XQjeE7XjC3Nzhi4KfIKrQZsBTlcf+/muyMgDs='.
HTTP 400

末尾の Base64 文字列は自分のヘッダーのハッシュなので、リクエストごとに変わります — これで照合してはいけません。メッセージが伝えているのは構造の問題です。AWS はアルゴリズムまでは読めたが、その後の Credential=/SignedHeaders=/Signature= のペアを読めなかった、ということです。これはヘッダーの組み立て方を指し示しており、だからこのエラーはほぼ必ず SDK ではなく自前の署名処理から生まれます。

関連するエラー

参考資料

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

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

Console なしで DynamoDB を扱う

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

ダウンロード料金を見る

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