InvalidSignatureException: Signature expired

TL;DR — A signed AWS request must reach the service within ~5 minutes of the timestamp baked into its signature. This error means your machine's clock is too far from AWS server time (clock skew), so the signature has "expired" or is "not yet current." Fix the client clock — enable NTP time sync.

What it means

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

Signature Version 4 signs each request together with a timestamp. AWS validates that timestamp against its own clock and rejects anything outside a roughly five-minute window — either Signature expired (client clock behind) or Signature not yet current (client clock ahead). It's an HTTP 400, client-side; a blind retry fails again until the clock is corrected.

Why it happens

• Client clock drift — the host running your app has an inaccurate clock (VM paused/resumed, container without time sync, IoT/edge device, CI runner).
• NTP not running — nothing keeps the OS clock disciplined, so it slowly drifts past the 5-minute tolerance.
• Wrong timezone/UTC handling in a hand-rolled signer that miscomputes the request timestamp.
• Long-suspended process — a laptop or Lambda-style environment resumed after a long pause with a stale sense of time.

How to fix it

1. Enable NTP time synchronization on the host (chrony/systemd-timesyncd/w32time) and confirm the clock is within a second of real UTC.
2. Compare clocks: check the client's UTC time against a trusted source — if it's off by minutes, that's the cause.
3. Restart the time sync service (or re-sync manually) after a VM resume or container start.
4. Upgrade the AWS SDK — modern SDKs detect clock-skew errors and auto-retry with a corrected offset; an old SDK may not.

Prefer the official AWS SDKs over a hand-written SigV4 signer so the timestamp and retry-on-skew handling are done for you.

In DynoTable

DynoTable relies on the AWS SDK for signing, which includes clock-skew correction on modern builds (Connect an AWS account). If this error appears only in a custom script but DynoTable connects fine, the problem is isolated to that client's clock or signer — compare against Test Connection on the profile in Settings → Profiles. On CI runners or VMs that hibernate, enable NTP before running either the app or your tests.

Modern AWS SDKs detect clock-skew errors and retry with a corrected offset; if you only see this in a hand-rolled signer, upgrade the SDK or enable NTP on the host before blaming DynamoDB itself. DynoTable uses the SDK path exclusively — no custom SigV4 assembly. The query builder confirms reads succeed once the clock and profile are aligned.

Related errors

• The security token expired — temporary credentials aged out (a different kind of "expired").
• The request signature we calculated does not match — signature mismatch from a bad key, not a clock.
• Credential should be scoped to a valid region — a region-scope SigV4 failure.

Sources

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