InvalidSignatureException: Signature expired

TL;DR — Ein signierter AWS-Request muss den Service innerhalb von etwa 5 Minuten nach dem Zeitstempel erreichen, der in seiner Signatur steckt. Dieser Fehler heißt, dass die Uhr deines Rechners zu weit von der AWS-Serverzeit abweicht (Clock Skew), sodass die Signatur „expired" oder „not yet current" ist. Korrigier die Uhr des Clients — aktivier die NTP-Zeitsynchronisierung.

Was es bedeutet

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

Signature Version 4 signiert jede Anfrage zusammen mit einem Zeitstempel. AWS validiert diesen Zeitstempel gegen die eigene Uhr und weist alles außerhalb eines etwa fünfminütigen Fensters ab — entweder Signature expired (Client-Uhr geht nach) oder Signature not yet current (Client-Uhr geht vor). Es ist ein HTTP 400, clientseitig; ein blinder Retry schlägt erneut fehl, bis die Uhr korrigiert ist.

Warum es passiert

• Client-Uhrendrift — der Host, der deine App ausführt, hat eine ungenaue Uhr (VM pausiert/fortgesetzt, Container ohne Zeitsynchronisation, IoT-/Edge-Gerät, CI-Runner).
• NTP läuft nicht — nichts hält die Betriebssystemuhr diszipliniert, sodass sie langsam über die 5-Minuten-Toleranz hinaus driftet.
• Falsche Zeitzonen-/UTC-Behandlung in einem selbstgebauten Signierer, der den Anfrage-Zeitstempel falsch berechnet.
• Lange ausgesetzter Prozess — ein Laptop oder eine Lambda-artige Umgebung, die nach einer langen Pause mit einem veralteten Zeitgefühl fortgesetzt wurde.

So behebst du es

1. Aktiviere die NTP-Zeitsynchronisation auf dem Host (chrony/systemd-timesyncd/w32time) und bestätige, dass die Uhr innerhalb einer Sekunde der echten UTC liegt.
2. Vergleiche die Uhren: prüfe die UTC-Zeit des Clients gegen eine vertrauenswürdige Quelle — wenn sie um Minuten abweicht, ist das die Ursache.
3. Starte den Zeitsynchronisationsdienst neu (oder synchronisiere manuell) nach einem VM-Resume oder Container-Start.
4. Aktualisiere das AWS SDK — moderne SDKs erkennen Uhrenversatz-Fehler und wiederholen automatisch mit einem korrigierten Offset; ein altes SDK tut das möglicherweise nicht.

Bevorzuge die offiziellen AWS SDKs gegenüber einem selbstgeschriebenen SigV4-Signierer, sodass der Zeitstempel und das Retry-on-Skew-Handling für dich erledigt werden.

In DynoTable

DynoTable überlässt das Signieren dem AWS SDK, das in modernen Builds eine Clock-Skew-Korrektur mitbringt (Ein AWS-Konto verbinden). Taucht dieser Fehler nur in einem eigenen Skript auf, während DynoTable sich problemlos verbindet, liegt das Problem isoliert bei der Uhr oder dem Signierer dieses Clients — vergleich es mit Verbindung testen am Profil unter Einstellungen → Profile. Auf CI-Runnern oder VMs, die in den Ruhezustand gehen, aktivier NTP, bevor du die App oder deine Tests startest.

Moderne AWS SDKs erkennen Clock-Skew-Fehler und wiederholen mit korrigiertem Offset; siehst du das nur bei einem selbstgebauten Signierer, aktualisier das SDK oder aktivier NTP auf dem Host, bevor du DynamoDB selbst verdächtigst. DynoTable nutzt ausschließlich den SDK-Pfad — kein eigener SigV4-Zusammenbau. Der Query Builder bestätigt, dass Lesevorgänge durchgehen, sobald Uhr und Profil zusammenpassen.

Verwandte Fehler

• The security token expired — temporäre Credentials sind gealtert (eine andere Art von „expired").
• The request signature we calculated does not match — Signatur-Mismatch durch einen schlechten Schlüssel, nicht durch eine Uhr.
• Credential should be scoped to a valid region — ein Fehler beim Region-Scoping von SigV4.

Quellen

• AWS Signature Version 4 for API requests — IAM User Guide (verified 2026-07-13 — five-minute replay window)
• Troubleshoot Signature Version 4 signing for AWS API requests — IAM User Guide (verified 2026-07-13)
• Error handling with DynamoDB — Amazon DynamoDB Developer Guide (verified 2026-07-13)
• Clock-skew correction — AWS Developer Tools Blog (verified 2026-07-13)