DynamoDB limitado em uma partição ativa apesar da capacidade

TL;DR — Sua tabela tem muitos RCU/WCU não utilizados em geral, mas você ainda está limitado porque uma única chave de partição está ativa. Cada partição física é projetada para fornecer um máximo de 3.000 unidades de leitura e 1.000 unidades de gravação por segundo, independentemente da capacidade da tabela. O tráfego acumulado em uma chave esgota essa partição. Distribua solicitações por chaves de partição mais distintas (fragmentação de gravação) para corrigi-lo.

O que significa

ProvisionedThroughputExceededException: You exceeded your maximum allowed
provisioned throughput for a table or for one or more global secondary indexes.
# ...yet CloudWatch shows consumed capacity well below provisioned.

O DynamoDB espalha uma tabela por muitas partições físicas e a capacidade de uma tabela é dividida entre elas. Uma partição individual foi projetada para fornecer no máximo 3.000 unidades de leitura e 1.000 unidades de gravação por segundo — em ambos os modos de capacidade. Se o seu padrão de acesso concentrar o tráfego em uma chave de partição, a partição dessa chave atingirá seu próprio teto e será limitado — mesmo que as métricas de toda a tabela pareçam subutilizadas (os campos ThrottlingReason do erro, por exemplo, TableReadKeyRangeThroughputExceeded, nomeiam o limite exato que foi atingido). A capacidade adaptativa ajuda, mas não consegue resgatar uma chave genuinamente desequilibrada.

Por que isso acontece

Chave de partição de baixa cardinalidade — um sinalizador de status, um booleano, uma "data atual" ou um único locatário que recebe a maior parte do tráfego.
Um item viral/celebridade — uma chave de partição popular (um produto de tendência, um usuário importante) atrai uma carga desproporcional.
Série temporal com chave "hoje" — cada gravação chega à mesma chave de partição baseada em data.
Uma chave sequencial ou monotônica escreve cluster na partição mais recente.
Um GSI com uma chave de partição de baixa cardinalidade, que limita as escritas da tabela base.

Como corrigir

Aumente a cardinalidade da chave. Projete a chave de partição de forma que as solicitações se espalhem por vários valores — esta é a solução mais eficaz.
Escrever e fragmentar a tecla de atalho. Anexe um sufixo (USER#42#1…USER#42#N) para que uma entidade lógica abranja diversas partições; espalhe as leituras pelos fragmentos.
Adicione aleatoriedade ou um sufixo calculado às chaves de série temporal para que as escritas de "hoje" não colidam.
Leituras dinâmicas em cache (DAX ou cache de aplicativo) para eliminar a pressão de leitura da partição ativa.
Manter novas tentativas de espera exponencial — esse erro pode ser repetido novamente e o SDK recua por padrão.
Corrigir chaves GSI de baixa cardinalidade — um GSI limitado acelera a tabela base.
Verifique ThrottlingReason no erro. Ele indica se o limite era específico para toda a tabela ou para o intervalo de chaves.

Confira o tamanho no DynoTable

Encontre a chave de partição ativa - abra a tabela com ⌘K, classifique por chave de partição e procure por uma chave que carregue muito mais itens do que vizinhos. Filtre para essa chave e inspecione os padrões de gravação antes de fragmentar novamente.

Modele sufixos de fragmentos de gravação no Query Builder e estime o tráfego de novas tentativas com a calculadora de preços. Alternar perfis com ⌘P; consulte Conectar ao AWS e Instalar.

Fontes

Práticas recomendadas para projetar chaves de partição (verificado em 13/07/2026)
Solução de problemas de limitação no Amazon DynamoDB (verificado em 13/07/2026)

FAQ

Por que o DynamoDB está me estrangulando quando a tabela tem capacidade ociosa? Porque uma única chave de partição é quente. Cada partição física tem um teto de cerca de 3.000 unidades de leitura e 1.000 unidades de gravação por segundo, independentemente da capacidade no nível da tabela, portanto, o tráfego acumulado em uma chave esgota essa partição, enquanto as métricas de toda a tabela parecem subutilizadas.

Como faço para corrigir uma partição ativa no DynamoDB? Aumente a cardinalidade da chave de partição para que as solicitações se espalhem por muitos valores, grave a chave de atalho com um sufixo, adicione um sufixo calculado às chaves de série temporal e armazene leituras de atalho em cache. As novas tentativas de espera exponencial ajudam a superar picos curtos, mas não corrigem uma chave desequilibrada.

Erros relacionados

ProvisionedThroughputExceededException — o erro geral de limitação e correções de capacidade.
ThrottlingException — limites de taxa da conta/control-plane.
Aprenda: Partições quentes · Como funcionam as chaves de partição

Referências

Última verificação em 13/07/2026 em relação à documentação oficial do AWS vinculada acima.