La firma de la solicitud que calculamos no coincide

TL;DR: AWS volvió a calcular la firma SigV4 para su solicitud a DynamoDB y obtuvo un valor distinto del que usted envió. Las causas habituales: una clave secreta incorrecta o que no coincide, reloj desfasado entre su máquina y AWS, o una solicitud canónica hecha a mano que está construida ligeramente mal. Arregle la llave o el reloj, o simplemente deje que un AWS SDK firme por usted.

Qué significa

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.

Cada petición a DynamoDB se firma con SigV4 usando tu clave secreta sobre una forma canónica de la petición. AWS vuelve a derivar la firma en el lado del servidor; si difiere, obtienes este HTTP 400. Es un fallo de autenticación (la identidad/firma), distinto de una denegación de autorización. Normalmente no es reintentable sin cambios — pero si es desfase de reloj, puede aparecer de forma intermitente.

Por qué ocurre

Clave de acceso secreta incorrecta — la AWS_SECRET_ACCESS_KEY no corresponde a la AWS_ACCESS_KEY_ID (claves mezcladas, un secreto rotado/antiguo, un espacio o salto de línea final perdido).
Desfase de reloj — la hora de la máquina se desvía de la de AWS; SigV4 incorpora la marca de tiempo de la petición en la firma, así que un reloj erróneo la rompe (clásico en VM/contenedores, p. ej. después de que una VM despierta de la hibernación).
Petición canónica construida a mano — un firmante personalizado que ordena mal las cabeceras/parámetros de consulta, codifica mal la URI o calcula el hash de la carga equivocada.
Caracteres especiales en la clave mal manejados — los secretos que contienen -, +, / o % pueden ser destrozados por shells o scripts que construyen archivos de credenciales; AWS sugiere regenerar la clave.
SigV2 legado — firmar con Signature Version 2, que servicios como Amazon S3 y las Regiones más nuevas ya no soportan.
Un proxy o gateway que muta la petición después de firmarla (añadiendo/reordenando cabeceras, recodificando la ruta).

Cómo solucionarlo

Vuelve a comprobar el par de claves. Regenera o vuelve a copiar la clave de acceso + el secreto y configúralos limpiamente (cuidado con espacios/saltos de línea finales, y regenera si el secreto contiene caracteres especiales que tu herramienta destroza).
Arregla el reloj. Activa NTP para que la hora del host sea precisa:
```
timedatectl status        # verify "System clock synchronized: yes"
```
Prefiere un SDK / CLI de AWS — deja que construya y firme la petición; toda esta clase de errores de petición canónica desaparece.
Si debes firmar a mano, sigue las reglas de la petición canónica de SigV4 exactamente (cabeceras ordenadas, ruta con codificación URI, x-amz-date, carga hasheada) y compara con la salida de --debug de la CLI.
Confirma que la identidad funciona con un cliente de confianza:
```
aws sts get-caller-identity
```

Reproducirlo

Firma con un ID de clave de acceso real pero con el secreto equivocado. Todo lo demás de la petición es válido, así que el fallo aísla la firma:

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

Salida real:

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

Fíjate en la clase. El mensaje es el familiar "signature we calculated does not match", pero DynamoDB lo devuelve como InvalidSignatureException — no como SignatureDoesNotMatch, que es lo que usan otros servicios de AWS para la misma situación. Si capturas por clase en lugar de hacer coincidir el mensaje, esa distinción es la diferencia entre un manejador que se dispara y uno que no lo hace nunca.

Míralo en DynoTable

DynoTable nunca te pide firmar peticiones a mano — usa la misma cadena de credenciales del SDK de AWS que la CLI (Conectar una cuenta de AWS). Si aws sts get-caller-identity funciona pero DynamoDB sigue lanzando este error, busca un proxy o middleware entre la app y AWS; DynoTable habla con DynamoDB directamente desde tu máquina, sin intermediarios. Tras arreglar las claves o el desfase de reloj, pulsa ⌘P para confirmar el perfil activo y ejecuta Test Connection en Ajustes → Perfiles antes de volver a abrir tablas.

Errores relacionados

The security token included in the request is invalid — las propias credenciales/token se rechazan.
IncompleteSignatureException — la cabecera Authorization está mal formada, no solo desajustada.
El token de seguridad ha caducado

Fuentes

Troubleshoot Signature Version 4 signing for AWS API requests — IAM User Guide (verificado 2026-07-13)
Troubleshooting errors for the AWS CLI — AWS CLI User Guide (verificado 2026-07-13)
Create a signed AWS API request — IAM User Guide (verificado 2026-07-13)

Reproducido el 2026-07-26 contra el servicio DynamoDB en vivo en us-east-1 — la salida de arriba es literal.