DynamoDB IncompleteSignatureException

TL;DR — Die AWS-Signature-Version-4-Signatur des Requests war unvollständig oder entsprach nicht den AWS-Vorgaben, also hat DynamoDB ihn vor der Authentifizierung abgelehnt. Mit einem AWS SDK läuft das Signieren automatisch — das heißt fast immer ein selbstgebauter Request oder ein Proxy/Gateway, der den Authorization-Header nach dem Signieren verändert hat. Lass das SDK signieren und sorg dafür, dass nichts den Request unterwegs umschreibt.

Was es bedeutet

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

AWS signiert jede Anfrage mit SigV4. Diese Exception bedeutet, dass die Signatur vorhanden war, aber fehlerhaft war oder erforderliche Komponenten fehlten — ein schlechter Authorization-Header, ein fehlender signierter Header oder ein Mismatch der Canonical Request. Es ist ein HTTP 400, clientseitig und so nicht wiederholbar: die Signatur muss korrigiert werden.

Warum es passiert

Selbstgebautes Signieren — du baust die SigV4-Signatur selbst (nicht über ein SDK) und die Canonical Request, die Liste der signierten Header oder der Authorization-Header ist falsch.
Ein fehlerhafter Authorization-Header — die dokumentierten Auslöser sind ein leerer Header, ein fehlender Credential- oder Signature-Parameter, ein Header, der nicht mit dem Algorithmusnamen (AWS4-HMAC-SHA256) beginnt, oder ein key=value-Paar ohne Gleichheitszeichen.
Ein Proxy oder API-Gateway hat die Anfrage umgeschrieben — die Mutation des Authorization-Headers (oder anderer signierter Teile) nach dem Signieren durch das SDK führt dazu, dass sich der Header, den AWS empfängt, von dem unterscheidet, den du gesendet hast.
Manuell bearbeitete Header — das Hinzufügen/Entfernen von Headern nach dem Signieren oder das Umsortieren des Query-Strings zerstört die Canonical Request.

So behebst du es

Verwende ein offizielles AWS SDK und lass es die Anfrage signieren. Die SDKs implementieren SigV4 korrekt für dich — der Fix für fast jedes Auftreten ist, mit dem Selbstsignieren aufzuhören.
Mutiere die Anfrage nicht nach dem Signieren — wenn ein Proxy/Gateway davor sitzt, stelle sicher, dass es keine Header hinzufügt, entfernt oder umsortiert oder Body/Pfad ändert. Signiere an der Kante, die die Anfrage tatsächlich sendet.
Prüfe, ob sich der Authorization-Header unterwegs geändert hat — die von AWS dokumentierte Diagnose: berechne einen SHA-256-Hash des gesendeten Headers, Base64-kodiere ihn und vergleiche ihn mit dem Hash, den einige IncompleteSignatureException-Meldungen enthalten. Wenn sie sich unterscheiden, hat etwas zwischen deinem Client und AWS den Header verändert.
Wenn du manuell signieren musst, folge dem AWS-SigV4-Signierprozess exakt — die Canonical Request, der String-to-Sign, die Ableitung des Signierschlüssels und der Authorization-Header (Algorithmus, Credential=, SignedHeaders=, Signature=) müssen alle übereinstimmen. Verifiziere gegen eine bekannt gute SDK-Anfrage.

Ein falscher oder abgeschnittener Secret Key ist ein anderer Fehler: er erzeugt eine vollständige Signatur, die nicht übereinstimmt, und zeigt sich als „signature we calculated does not match" statt als dieser Fehler. Ebenso zeigt sich eine schiefe Rechneruhr als Signature expired, nicht als unvollständige Signatur.

DynoTable + Local

DynoTable uses the AWS SDK signing path — no hand-built SigV4 — so this error class does not appear in normal use. Wenn your app hits it während DynoTable works, compare proDateien auf: Einstellungen → Profile → Verbindung testen with the same keys your app loads.

Für Local, dummy credentials on a profile with endpoint http://localhost:8000 bypasses signing entirely. Siehe Mit AWS verbinden und Installation. Nachdem credentials resolve, run a smoke-test query in the Query Builder.

Quellen

Error handling with DynamoDB — IncompleteSignatureException (verifiziert 2026-07-13)
Troubleshoot Signature Version 4 signing (verifiziert 2026-07-13)

FAQ

Was verursacht eine IncompleteSignatureException? Die AWS-SigV4-Signatur der Anfrage war fehlerhaft oder es fehlten erforderliche Teile — ein leerer oder fehlerhafter Authorization-Header, ein fehlender Credential- oder Signature-Parameter oder ein key=value-Paar ohne Gleichheitszeichen. Mit einem AWS SDK erfolgt das Signieren automatisch, deshalb bedeutet es meist eine selbstgebaute Signatur oder einen Proxy, der die Anfrage nach dem Signieren verändert hat.

Wie unterscheidet sich das von UnrecognizedClientException? IncompleteSignatureException bedeutet, dass die Signatur selbst fehlerhaft war. UnrecognizedClientException („security token is invalid") bedeutet, dass die Signatur wohlgeformt war, aber die dahinterstehenden Credentials nicht akzeptiert wurden.

So reproduzierst du es

Schick einen Authorization-Header, der zwar vorhanden, aber nicht als SigV4 parsebar ist:

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='{}',
)

Echte Ausgabe:

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

The trailing Base64 string is a hash of your own header, so it differs on every request — do not match on it. What the message is telling you is structural: AWS could read the algorithm but not the Credential=/SignedHeaders=/Signature= pairs nachdem it. That points at how the header was assembled, which is why this almost always comes from hand-rolled signing rather than from an SDK.

Referenzen

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.

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