The request signature we calculated does not match

TL;DR — AWS a recalculé la signature SigV4 de ta requête DynamoDB et a obtenu une valeur différente de celle que tu as envoyée. Les causes habituelles : une clé secrète erronée/incohérente, un décalage d'horloge entre ta machine et AWS, ou une requête canonique construite à la main légèrement mal formée. Corrige la clé ou l'horloge — ou laisse simplement un SDK AWS signer à ta place.

Ce que ça signifie

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.

Chaque requête DynamoDB est signée avec SigV4 en utilisant ta clé secrète sur une forme canonique de la requête. AWS redérive la signature côté serveur ; si elle diffère, tu obtiens ce HTTP 400. C'est un échec d'authentification (l'identité/signature), distinct d'un refus d'autorisation. Normalement non réessayable en l'état — mais s'il s'agit d'un décalage d'horloge, il peut apparaître de manière intermittente.

Pourquoi ça arrive

Mauvaise clé d'accès secrète — la AWS_SECRET_ACCESS_KEY ne correspond pas à l'AWS_ACCESS_KEY_ID (clés mélangées, un secret ancien/pivoté, une espace ou un saut de ligne parasite en fin).
Décalage d'horloge — l'heure de la machine dérive par rapport à AWS ; SigV4 intègre l'horodatage de la requête dans la signature, donc une horloge erronée la casse (classique dans les VMs/conteneurs, par exemple après le réveil d'une VM après hibernation).
Requête canonique construite à la main — un signeur personnalisé qui ordonne mal les en-têtes/paramètres de requête, encode mal l'URI, ou hache la mauvaise charge utile.
Caractères spéciaux dans la clé mal gérés — les secrets contenant -, +, / ou % peuvent être altérés par des shells ou scripts qui construisent des fichiers d'identifiants ; AWS suggère de régénérer la clé.
SigV2 legacy — signer avec Signature Version 2, que des services comme Amazon S3 et les Régions plus récentes ne prennent plus en charge.
Un proxy ou une passerelle qui modifie la requête après signature (ajout/réordonnancement d'en-têtes, réencodage du chemin).

Comment le corriger

Revérifie la paire de clés. Régénère ou recopie la clé d'accès + le secret et définis-les proprement (attention aux espaces/sauts de ligne en fin, et régénère si le secret contient des caractères spéciaux que ton outillage altère).
Corrige l'horloge. Active NTP pour que l'heure de l'hôte soit exacte :
```
timedatectl status        # verify "System clock synchronized: yes"
```
Préfère un SDK / CLI AWS — laisse-le construire et signer la requête ; toute la classe de bugs de requête canonique disparaît.
Si tu dois signer à la main, suis exactement les règles de requête canonique SigV4 (en-têtes triés, chemin encodé en URI, x-amz-date, charge utile hachée) et compare avec la sortie --debug de la CLI.
Confirme que l'identité fonctionne avec un client connu comme correct :
```
aws sts get-caller-identity
```

Reproduire l'erreur

Signe avec un vrai identifiant de clé d'accès, mais le mauvais secret. Tout le reste de la requête est valide, l'échec isole donc bien la 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()

Sortie réelle :

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 la classe. Le message est le familier « signature we calculated does not match », mais DynamoDB le renvoie sous InvalidSignatureException — et non SignatureDoesNotMatch, que plusieurs autres services AWS utilisent pour la même situation. Si tu attrapes par classe plutôt qu'en filtrant le message, cette nuance fait la différence entre un handler qui se déclenche et un handler qui ne se déclenche jamais.

Vois-le dans DynoTable

DynoTable ne te demande jamais de signer les requêtes à la main — il emprunte la même chaîne d'identifiants du SDK AWS que la CLI (Connecter un compte AWS). Si aws sts get-caller-identity réussit mais que DynamoDB lève quand même cette erreur, cherche un proxy ou un middleware entre l'app et AWS ; DynoTable parle à DynamoDB directement depuis ta machine, sans intermédiaire. Après avoir corrigé les clés ou la dérive d'horloge, appuie sur ⌘P pour confirmer le profil actif et lance Test Connection dans Settings → Profiles avant de rouvrir des tables.

Erreurs liées

The security token included in the request is invalid — les identifiants/le token eux-mêmes sont rejetés.
IncompleteSignatureException — l'en-tête Authorization est malformé, pas seulement incohérent.
The security token has expired

Sources

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.

Reproduit le 2026-07-26 sur le service DynamoDB réel dans us-east-1 — la sortie ci-dessus est reproduite telle quelle.