The request signature we calculated does not match

TL;DR — AWS 重新計算了你 DynamoDB 請求的 SigV4 簽名，得到的值與你發來的不同。常見成因：金鑰錯誤或與訪問金鑰不配套、你的機器與 AWS 之間存在時鐘偏移，或者一個手寫的規範請求哪裡構造得略有偏差。修好金鑰或時鐘——又或者乾脆讓 AWS SDK 替你簽名。

這是什麼意思

InvalidSignatureException: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

每個 DynamoDB 請求都用你的金鑰、對請求的規範形式做 SigV4 簽名。AWS 會在伺服器端重新推導這個簽名；如果不一致，你就得到這個 HTTP 400。這是一次認證失敗（身份/簽名），與授權被拒絕不同。原樣通常不可重試——但如果成因是時鐘偏移，它可能表現為時有時無。

為什麼會發生

金鑰錯誤——AWS_SECRET_ACCESS_KEY 與 AWS_ACCESS_KEY_ID 不對應（金鑰搞混了、金鑰被輪換過、或者末尾多了一個空格或換行）。
時鐘偏移——機器時間與 AWS 有漂移；SigV4 會把請求時間戳揉進簽名，所以時鐘不對就會把簽名破壞掉（在虛擬機器/容器裡很典型，比如虛擬機器從休眠中喚醒之後）。
手工構造的規範請求——某個自定義簽名器把頭部/查詢引數排錯了序、URI 編碼有誤，或者雜湊了錯誤的負載。
金鑰中的特殊字元被處理壞了——含有 -、+、/ 或 % 的金鑰，可能被那些生成憑證檔案的 shell 或指令碼弄壞；AWS 建議重新生成金鑰。
老舊的 SigV2——用 Signature Version 2 簽名，而像 Amazon S3 這樣的服務和較新的區域已經不再支援它。
某個代理或閘道器在簽名之後改動了請求（新增/重排頭部、對路徑重新編碼）。

如何修正

重新核對這對金鑰。重新生成或重新複製訪問金鑰 + 金鑰，並乾淨地設定好（留意末尾的空白/換行；如果金鑰裡的特殊字元會被你的工具鏈弄壞，就重新生成一個）。

修好時鐘。啟用 NTP，讓主機時間準確：

timedatectl status        # verify "System clock synchronized: yes"

優先使用 AWS SDK / CLI——讓它來構造並簽名請求；整整一類規範請求的 bug 就此消失。
如果你必須手工簽名，就嚴格遵循 SigV4 的規範請求規則（頭部排序、URI 編碼的路徑、x-amz-date、雜湊後的負載），並與 CLI 的 --debug 輸出比對。
用一個已知可用的用戶端確認身份沒問題：
```
aws sts get-caller-identity
```

重現方式

使用真實的訪問金鑰 ID 進行簽名，但密碼錯誤。有關請求的其他所有內容都是有效的，因此失敗會隔離簽名：

import boto3
boto3.client(
    'dynamodb',
    region_name='us-east-1',
    aws_access_key_id='AKIA...',                      # a real key id
    aws_secret_access_key='deliberately-the-wrong-secret',
).list_tables()

實際輸出：

InvalidSignatureException: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
HTTP 400

注意該類。 該訊息是熟悉的“我們計算的簽名不匹配”，但 DynamoDB 將其返回為 InvalidSignatureException — 而不是 SignatureDoesNotMatch，這是其他幾個 AWS 服務在相同情況下使用的。如果你按類捕獲而不是匹配訊息，則這種區別就是觸發的處理程式和從不觸發的處理程式之間的區別。

在 DynoTable 中檢視

DynoTable 從不要求你手動簽署請求 - 它使用相同的 AWS SDK 憑證鏈作為 CLI (Connect an AWS account)。如果 aws sts get-caller-identity成功但DynamoDB仍然丟擲此錯誤，檢查應用程式和 AWS 之間的代理或中介軟體； DynoTable 交談 DynamoDB 直接從你的機器進行，無需中介。修復按鍵後或時鐘偏差，若修復了金鑰或時鐘偏差，按 ⌘P 確認活動設定檔案，並在再次開啟表之前於 設定 → 設定檔案 中執行 測試連線。

來源

Troubleshoot Signature Version 4 signing for AWS API requests — IAM User Guide（2026-07-13 驗證）
Troubleshooting errors for the AWS CLI — AWS CLI User Guide（2026-07-13 驗證）
Create a signed AWS API request — IAM User Guide（2026-07-13 驗證）

根據 us-east-1 中的實時 DynamoDB 服務於 2026 年 7 月 26 日轉載 — 上面的輸出是逐字記錄的。