DynamoDB Streams ganha shard iterator AT_TIMESTAMP para retomar leitura a partir de um horário exato

A AWS publicou em 15 de outubro de 2026 um recurso que muda a forma de consumir o DynamoDB Streams: agora dá para começar a ler registros a partir de um timestamp específico. Antes, só existiam dois pontos de partida possíveis: o registro mais antigo retido (até 24 horas de histórico) ou os registros novos gravados depois que o consumidor começa a rodar. Quem precisava recomeçar de um ponto intermediário tinha que escolher entre reprocessar o stream inteiro ou arriscar perder registros.

O novo tipo de iterador se chama AT_TIMESTAMP. Ele instrui o GetShardIterator a posicionar a leitura no primeiro registro gravado naquele instante ou depois dele. Para quem trabalha com DynamoDB Streams todo dia, isso fecha uma lacuna que existia desde o lançamento do serviço: nunca houve como dizer "comece a ler a partir das 3h da manhã de ontem" sem construir essa lógica na mão, geralmente guardando sequence numbers em algum lugar.

Como pedir o iterador por timestamp

Na prática, a chamada ao GetShardIterator ganha um novo valor de ShardIteratorType e um parâmetro Timestamp. Um exemplo via AWS CLI, apontando para uma tabela na região São Paulo:

aws dynamodbstreams get-shard-iterator \
 --stream-arn arn:aws:dynamodb:sa-east-1:123456789012:table/Pedidos/stream/2026-10-15T00:00:00.000 \
 --shard-id shardId-00000001 \
 --shard-iterator-type AT_TIMESTAMP \
 --timestamp 2026-10-20T03:00:00Z

O iterador retornado já aponta para o primeiro registro gravado às 3h do dia 20 de outubro ou depois disso. A partir daí, o fluxo de leitura com GetRecords segue exatamente como antes: você pagina pelos NextShardIterator até esvaziar o shard. Não existe cobrança adicional para usar AT_TIMESTAMP além das chamadas normais de GetRecords que você já faz hoje.

Quem usa KCL também ganha o recurso

Quem consome o DynamoDB Streams por meio do Kinesis Client Library (KCL), via o adaptador DynamoDB Streams Kinesis Adapter, não precisa reescrever a aplicação inteira para aproveitar o timestamp. O adaptador expõe a mesma capacidade de posicionamento, então pipelines já construídos sobre KCL podem configurar o ponto de retomada sem trocar de biblioteca.

Isso importa para quem roda arquiteturas de processamento de eventos em produção: boa parte das aplicações que leem DynamoDB Streams no Brasil usa KCL justamente porque ele resolve checkpoint, balanceamento de shards e failover entre workers. Ter AT_TIMESTAMP disponível nesse caminho evita ter que sair do padrão estabelecido só para resolver um problema de retomada.

Os casos de uso que a AWS lista

A própria AWS descreve quatro cenários onde o recurso resolve um problema real de quem opera DynamoDB Streams:

• Recuperação após uma interrupção: se o consumidor caiu por algumas horas, dá para retomar exatamente de onde parou, sem reler tudo.
• Replay de dados para depuração e auditoria: ler de um ponto específico do passado para investigar o que aconteceu num incidente, sem precisar do stream inteiro.
• Pular um backlog acumulado: se o consumidor ficou muito atrás, é possível saltar para perto dos registros mais recentes em vez de processar tudo que se acumulou.
• Sincronizar depois de uma restauração: começar a ler a partir do timestamp de export de um point-in-time recovery (PITR), garantindo que o stream retome exatamente de onde a restauração parou.

Esse último ponto é especialmente útil para quem combina PITR com Streams em pipelines de replicação ou de reconstrução de índices: antes, calcular o ponto certo de retomada depois de um restore exigia malabarismo com sequence numbers; agora o timestamp do export já serve como entrada direta.

Disponibilidade e o que ainda não muda

O recurso está disponível em todas as regiões comerciais da AWS, nas regiões AWS GovCloud (US) e nas regiões da China, o que inclui a região São Paulo (sa-east-1) desde o lançamento, sem espera por rollout regional. Não há mudança na janela de retenção do Streams, que continua em até 24 horas: AT_TIMESTAMP ajuda a escolher onde começar dentro dessa janela, mas não estende quanto tempo o DynamoDB guarda os registros.

Vale lembrar que o recurso resolve o posicionamento inicial da leitura, não troca a mecânica de consumo. Quem já tem lógica própria de checkpoint baseada em sequence number continua podendo usá-la; AT_TIMESTAMP é uma alternativa para os casos em que guardar e recuperar um sequence number é mais trabalhoso do que guardar um horário. A documentação de referência está no guia do desenvolvedor do DynamoDB, na seção sobre o DynamoDB Streams.

Fonte: AWS What's New