A assinatura da solicitação que calculamos não corresponde

TL;DR — AWS recomputou a assinatura SigV4 para sua solicitação DynamoDB e obteve um valor diferente daquele que você enviou. As causas comuns: uma chave secreta /mismatched errada, diferença de relógio entre sua máquina e AWS ou uma solicitação canônica feita à mão que foi construída um pouco errada. Corrija a chave ou o relógio – ou apenas deixe um SDK AWS assinar para você.

O que 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 solicitação DynamoDB é assinada com SigV4 usando sua chave secreta em uma forma canônica da solicitação. AWS deriva novamente a assinatura do lado do servidor; se for diferente, você obterá este HTTP 400. É uma falha de autenticação (a identidade/signature), distinta de uma negação de autorização. Normalmente não é possível tentar novamente inalterado - mas se o relógio estiver distorcido, pode parecer intermitente.

Por que isso acontece

Chave de acesso secreta errada — o AWS_SECRET_ACCESS_KEY não corresponde ao AWS_ACCESS_KEY_ID (chaves misturadas, um segredo /old girado, um espaço à direita perdido ou nova linha).
Distorção do relógio — o tempo da máquina difere do AWS; O SigV4 dobra o carimbo de data/hora da solicitação na assinatura, de modo que um relógio errado o interrompe (clássico em VMs/containers, por exemplo, depois que uma VM sai da hibernação).
Solicitação canônica feita à mão — um assinante personalizado que ordena os parâmetros dos cabeçalhos/query de maneira errada, codifica incorretamente o URI ou faz hash da carga útil errada.
Caracteres especiais na chave maltratados — segredos contendo -, +, / ou % podem ser mutilados por shells ou scripts que criam arquivos de credenciais; AWS sugere regenerar a chave.
SigV2 legado — assinatura com Signature versão 2, cujos serviços como Amazon S3 e regiões mais recentes não são mais compatíveis.
Um proxy ou gateway alterando a solicitação após a assinatura (adicionando cabeçalhos /reordering, recodificando o caminho).

Como corrigir

Verifique novamente o par de chaves. Gere novamente ou copie novamente a chave de acesso + segredo e configure-os de forma limpa (observe o espaço em branco à direita/newlines e gere novamente se o segredo contiver caracteres especiais que suas ferramentas deturpam).
Corrija o relógio. Habilite o NTP para que a hora do host seja precisa:
```
timedatectl status        # verify "System clock synchronized: yes"
```
Prefira um SDK / a CLI da AWS — deixe que ele construa e assine a requisição; toda a classe de bugs de canonical-request desaparece.
Se você precisa mesmo assinar à mão, siga exatamente as regras de canonical-request do SigV4 (cabeçalhos ordenados, path codificado por URI, x-amz-date, payload com hash) e compare com a saída de --debug da CLI.
Confirme que a identidade funciona com um cliente sabidamente bom:
```
aws sts get-caller-identity
```

Reproduza

Assine com um ID de chave de acesso real, mas com o segredo errado. Todo o resto da solicitação é válido, portanto a falha isola a assinatura:

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

Saída 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

Observe a classe. A mensagem é a familiar "assinatura que calculamos não corresponde", mas DynamoDB a retorna como InvalidSignatureException - não SignatureDoesNotMatch, que é o que vários outros serviços AWS usam para a mesma situação. Se você estiver capturando por classe em vez de corresponder à mensagem, essa distinção é a diferença entre um manipulador que é acionado e outro que nunca o faz.

Veja no DynoTable

O DynoTable nunca pede que você assine solicitações manualmente – ele usa o mesmo SDK do AWS cadeia de credenciais como CLI (Conectar uma conta AWS). Se aws sts get-caller-identity é bem-sucedido, mas DynamoDB ainda gera este erro, verifique se há um proxy ou middleware entre o aplicativo e o AWS; DynoTable fala com DynamoDB diretamente da sua máquina sem intermediário. Depois de consertar chaves ou inclinação do relógio, pressione ⌘P para confirmar o perfil ativo e execute Test Conexão em Configurações → Perfis antes de abrir as tabelas novamente.

Erros relacionados

O token de segurança incluído na solicitação é inválido — as próprias credenciais/token são rejeitadas.
IncompleteSignatureException — o cabeçalho Authorization está malformado, e não apenas incompatível.
O token de segurança expirou

Fontes

Solucionar problemas de assinatura da versão 4 para solicitações AWS API - Guia do usuário IAM (verificado em 13/07/2026)
Solução de erros para o AWS CLI - Guia do usuário do AWS CLI (verificado em 13/07/2026)
Crie uma solicitação AWS API assinada - Guia do usuário IAM (verificado em 13/07/2026)

Reproduzido em 26/07/2026 no serviço DynamoDB ativo em us-east-1 - a saída acima é literal.