The request signature we calculated does not match

TL;DR — AWS recomputed the SigV4 signature for your DynamoDB request and got a different value than the one you sent. The usual causes: a wrong/mismatched secret key, clock skew between your machine and AWS, or a hand-rolled canonical request that's built slightly wrong. Fix the key or the clock — or just let an AWS SDK sign for you.

What it means

SignatureDoesNotMatch: The request signature we calculated does not match
the signature you provided. Check your AWS Secret Access Key and signing method.

Every DynamoDB request is signed with SigV4 using your secret key over a canonical form of the request. AWS re-derives the signature server-side; if it differs, you get this HTTP 403. It's an authentication failure (the identity/signature), distinct from an authorization denial. Normally not retryable unchanged — but if it's clock skew, it can appear intermittent.

Why it happens

• Wrong secret access key — the AWS_SECRET_ACCESS_KEY doesn't correspond to the AWS_ACCESS_KEY_ID (mixed-up keys, a rotated/old secret, a stray trailing space or newline).
• Clock skew — the machine's time drifts from AWS; SigV4 folds the request timestamp into the signature, so a wrong clock breaks it (classic in VMs/containers).
• Hand-built canonical request — a custom signer that orders headers/query params wrong, mis-encodes the URI, or hashes the wrong payload.
• Legacy SigV2 — signing with the retired Signature Version 2 instead of SigV4.
• A proxy or gateway mutating the request after signing (adding/reordering headers, re-encoding the path).
• Secret leaked into logs and truncated when copied.

How to fix it

1. Re-check the key pair. Regenerate or re-copy the access key + secret and set them cleanly (watch for trailing whitespace/newlines).
2. Fix the clock. Enable NTP so the host time is accurate:

   timedatectl status        # verify "System clock synchronized: yes"

3. Prefer an AWS SDK / CLI — let it construct and sign the request; the whole class of canonical-request bugs disappears.
4. If you must sign by hand, follow the SigV4 canonical-request rules exactly (sorted headers, URI-encoded path, x-amz-date, hashed payload) and compare against the CLI's --debug output.
5. Confirm the identity works with a known-good client:

   aws sts get-caller-identity

Related errors

• The security token included in the request is invalid — the credentials/token themselves are rejected.
• IncompleteSignatureException — the Authorization header is malformed, not just mismatched.
• The security token has expired