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

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.

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 400. 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, e.g. after a VM wakes from hibernation).
Hand-built canonical request — a custom signer that orders headers/query params wrong, mis-encodes the URI, or hashes the wrong payload.
Special characters in the key mishandled — secrets containing -, +, /, or % can be mangled by shells or scripts that build credential files; AWS suggests regenerating the key.
Legacy SigV2 — signing with Signature Version 2, which services such as Amazon S3 and newer Regions no longer support.
A proxy or gateway mutating the request after signing (adding/reordering headers, re-encoding the path).

How to fix it

Re-check the key pair. Regenerate or re-copy the access key + secret and set them cleanly (watch for trailing whitespace/newlines, and regenerate if the secret contains special characters your tooling mangles).

Fix the clock. Enable NTP so the host time is accurate:

timedatectl status        # verify "System clock synchronized: yes"

Prefer an AWS SDK / CLI — let it construct and sign the request; the whole class of canonical-request bugs disappears.
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.
Confirm the identity works with a known-good client:
```
aws sts get-caller-identity
```

Reproduce it

Sign with a real access key ID but the wrong secret. Everything else about the request is valid, so the failure isolates the signature:

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

Real output:

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

Note the class. The message is the familiar "signature we calculated does not match", but DynamoDB returns it as InvalidSignatureException — not SignatureDoesNotMatch, which is what several other AWS services use for the same situation. If you are catching by class rather than matching the message, that distinction is the difference between a handler that fires and one that never does.

See it in DynoTable

DynoTable never asks you to hand-sign requests — it uses the same AWS SDK credential chain as the CLI (Connect an AWS account). If aws sts get-caller-identity succeeds but DynamoDB still throws this error, check for a proxy or middleware between the app and AWS; DynoTable talks to DynamoDB directly from your machine with no intermediary. After fixing keys or clock skew, press ⌘P to confirm the active profile and run Test Connection in Settings → Profiles before opening tables again.

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

Sources

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)

Reproduced 2026-07-26 against the live DynamoDB service in us-east-1 — the output above is verbatim.