The request signature we calculated does not match

TL;DR — AWS hat die SigV4-Signatur für deinen DynamoDB-Request neu berechnet und einen anderen Wert erhalten als den, den du gesendet hast. Die üblichen Ursachen: ein falscher oder nicht passender Secret Key, Uhr-Abweichung zwischen deiner Maschine und AWS, oder ein von Hand gebauter Canonical Request mit einem kleinen Fehler. Korrigiere den Schlüssel oder die Uhr — oder lass einfach ein AWS-SDK für dich signieren.

Was es bedeutet

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.

Jeder DynamoDB-Request wird mit SigV4 unter Verwendung deines Secret Keys über eine kanonische Form des Requests signiert. AWS leitet die Signatur serverseitig neu ab; weicht sie ab, bekommst du dieses HTTP 400. Es ist ein Authentifizierungs-Fehler (die Identität/Signatur), verschieden von einer Autorisierungs-Ablehnung. Normalerweise unverändert nicht wiederholbar — aber wenn es Uhr-Abweichung ist, kann er sporadisch auftreten.

Warum es passiert

Falscher Secret Access Key — der AWS_SECRET_ACCESS_KEY entspricht nicht der AWS_ACCESS_KEY_ID (vertauschte Schlüssel, ein rotierter/alter Secret, ein versehentliches nachgestelltes Leerzeichen oder Zeilenumbruch).
Uhr-Abweichung — die Zeit der Maschine driftet von AWS ab; SigV4 bindet den Request-Zeitstempel in die Signatur ein, sodass eine falsche Uhr sie bricht (klassisch in VMs/Containern, z. B. nachdem eine VM aus dem Ruhezustand erwacht).
Von Hand gebauter Canonical Request — ein eigener Signer, der Header/Query-Parameter falsch ordnet, die URI falsch kodiert oder das falsche Payload hasht.
Sonderzeichen im Schlüssel falsch behandelt — Secrets, die -, +, / oder % enthalten, können von Shells oder Skripten, die Credential-Dateien bauen, verstümmelt werden; AWS empfiehlt, den Schlüssel neu zu generieren.
Legacy SigV2 — Signieren mit Signature Version 2, was Dienste wie Amazon S3 und neuere Regionen nicht mehr unterstützen.
Ein Proxy oder Gateway, das den Request nach dem Signieren verändert (Header hinzufügt/umordnet, den Pfad neu kodiert).

So behebst du es

Prüfe das Schlüsselpaar erneut. Generiere oder kopiere Access Key + Secret neu und setze sie sauber (achte auf nachgestellte Leerzeichen/Zeilenumbrüche und generiere neu, falls der Secret Sonderzeichen enthält, die dein Tooling verstümmelt).
Behebe die Uhr. Aktiviere NTP, damit die Host-Zeit korrekt ist:
```
timedatectl status        # verify "System clock synchronized: yes"
```
Bevorzuge ein AWS-SDK / eine CLI — lass es den Request konstruieren und signieren; die ganze Klasse von Canonical-Request-Bugs verschwindet.
Falls du von Hand signieren musst, befolge die SigV4-Canonical-Request-Regeln exakt (sortierte Header, URI-kodierter Pfad, x-amz-date, gehashtes Payload) und vergleiche mit der --debug-Ausgabe der CLI.
Bestätige, dass die Identität funktioniert mit einem bekannt guten Client:
```
aws sts get-caller-identity
```

So reproduzierst du es

Signiere mit einer echten Access Key ID, aber dem falschen Secret. Alles andere am Request ist gültig, sodass der Fehlschlag die Signatur isoliert:

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()

Echte Ausgabe:

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

Achte auf die Klasse. Die Meldung ist das vertraute "signature we calculated does not match", aber DynamoDB gibt sie als InvalidSignatureException zurück — nicht als SignatureDoesNotMatch, was mehrere andere AWS-Dienste in derselben Situation verwenden. Fängst du nach Klasse statt nach Meldungstext ab, ist dieser Unterschied genau die Grenze zwischen einem Handler, der greift, und einem, der nie greift.

In DynoTable ansehen

DynoTable verlangt nie, dass du Requests von Hand signierst — es nutzt dieselbe Credential-Kette des AWS SDK wie die CLI (Ein AWS-Konto verbinden). Läuft aws sts get-caller-identity erfolgreich, während DynamoDB diesen Fehler weiterhin wirft, suche nach einem Proxy oder einer Middleware zwischen App und AWS; DynoTable spricht ohne Zwischenstation direkt von deiner Maschine mit DynamoDB. Nachdem du Schlüssel oder Uhr-Abweichung korrigiert hast, drücke ⌘P, um das aktive Profil zu bestätigen, und führe unter Einstellungen → Profile Verbindung testen aus, bevor du wieder Tabellen öffnest.

Quellen

Troubleshoot Signature Version 4 signing for AWS API requests — IAM User Guide (verified 2026-07-13)
Troubleshooting errors for the AWS CLI — AWS CLI User Guide (verified 2026-07-13)
Create a signed AWS API request — IAM User Guide (verified 2026-07-13)

Am 2026-07-26 gegen den Live-DynamoDB-Dienst in us-east-1 reproduziert — die Ausgabe oben ist wortgetreu.