DynoTable

InvalidSignatureException: assinatura expirada

TL;DR — Uma solicitação AWS assinada deve chegar ao serviço dentro de aproximadamente 5 minutos após o carimbo de data/hora inserido em sua assinatura. Este erro significa que o relógio da sua máquina está muito longe do horário do servidor AWS (desvio do relógio), então a assinatura "expirou" ou "ainda não é atual". Corrija o relógio do cliente – habilite a sincronização de horário NTP.

O que significa

InvalidSignatureException: Signature expired: 20260712T101500Z is now earlier
than 20260712T101700Z (20260712T102200Z - 5 min.)

A assinatura versão 4 assina cada solicitação junto com um carimbo de data/hora. O AWS valida esse carimbo de data/hora em seu próprio relógio e rejeita qualquer coisa fora de uma janela de aproximadamente cinco minutos — seja Signature expired (relógio do cliente atrasado) ou Signature not yet current (relógio do cliente adiantado). É um HTTP 400 do lado do cliente; uma nova tentativa cega falha novamente até que o relógio seja corrigido.

Por que isso acontece

  • Desvio do relógio do cliente — o host que executa seu aplicativo tem um relógio impreciso (VM pausada/resumed, contêiner sem sincronização de horário, dispositivo IoT/edge, executor de CI).
  • NTP não está em execução — nada mantém o relógio do sistema operacional disciplinado, então ele ultrapassa lentamente a tolerância de 5 minutos.
  • Fuso horário/manuseio UTC errado em um signatário rolado manualmente que calcula incorretamente o carimbo de data/hora da solicitação.
  • Processo suspenso por muito tempo — um laptop ou ambiente estilo Lambda retomado após uma longa pausa com uma sensação de tempo obsoleta.

Como corrigir

  1. Ative a sincronização de horário NTP no host (chrony/systemd-timesyncd/w32time) e confirme se o relógio está dentro de um segundo do UTC real.
  2. Compare relógios: verifique o horário UTC do cliente em relação a uma fonte confiável. Se estiver atrasado em minutos, essa é a causa.
  3. Reinicie o serviço de sincronização de horário (ou sincronize novamente manualmente) após a retomada da VM ou início do contêiner.
  4. Atualize o SDK AWS — SDKs modernos detectam erros de distorção do relógio e tentam novamente automaticamente com um deslocamento corrigido; um SDK antigo pode não.

Prefira os SDKs AWS oficiais em vez de um assinante SigV4 escrito à mão para que o carimbo de data e hora e o tratamento de novas tentativas sejam feitos para você.

No DynoTable

DynoTable depende do SDK AWS para assinatura, que inclui distorção de relógio correção em compilações modernas (Conectar uma conta AWS). Se este erro aparece apenas em um script personalizado, mas o DynoTable se conecta bem, o o problema está isolado no relógio ou assinante desse cliente - compare com Teste Conexão no perfil em Configurações → Perfis. Em executores de CI ou VMs que hibernam, ative o NTP antes de executar o aplicativo ou seus testes.

Os SDKs AWS modernos detectam erros de distorção do relógio e tentam novamente com um deslocamento corrigido; se você veja isso apenas em um assinante enrolado manualmente, atualize o SDK ou habilite o NTP no host antes de culpar o próprio DynamoDB. DynoTable usa exclusivamente o caminho do SDK – não montagem SigV4 personalizada. O construtor de consultas confirma as leituras são bem-sucedidas quando o relógio e o perfil estão alinhados.

Erros relacionados

Fontes

Trabalhe com o DynamoDB sem o Console

Um cliente desktop rápido para DynamoDB que roda o SQL de verdade que o DynamoDB não consegue — JOINs, GROUP BY, agregações — com edição visual e um agente de IA com suas próprias chaves do Bedrock.

BaixarVer preços

Teste grátis de 30 dias, sem cartão de crédito — depois o plano Grátis sem limite de tempo.