Provisioned throughput decreases are limited within a given day

TL;DR — O DynamoDB limita quantas vezes você pode reduzir a capacidade provisionada de leitura/escrita de uma tabela (ou GSI) em um único dia UTC. Você usou a cota, então o UpdateTable é rejeitado. Espere a recarga por hora, agrupe sua redução em menos passos maiores, ou mude a tabela para on-demand e pare de gerenciar reduções inteiramente.

O que significa

LimitExceededException: Subscriber limit exceeded: Provisioned throughput
decreases are limited within a given UTC day

Cada tabela começa um dia UTC com um pequeno orçamento de reduções de capacidade (aumentos podem ser feitos tão frequentemente quanto necessário, sujeitos a quotas de conta e ao DynamoDB não deixar você aumentar rápido demais). Você começa o dia com 4 reduções disponíveis, e ganha mais 1 a cada hora até um máximo de 4 disponíveis a qualquer momento — suficiente para até 27 reduções ao longo de um dia completo de 24 horas. Esgote-o e chamadas UpdateTable de redução adicionais falham com um LimitExceededException (HTTP 400; a mensagem genérica do developer guide para esta exceção é "Too many operations for a given subscriber.") até que o orçamento recarregue. É uma quota, então tentar novamente às cegas não ajudará dentro da mesma janela.

Por que isso acontece

Auto-scaling oscilando — uma carga de trabalho instável faz o auto-scaling do DynamoDB reduzir a capacidade repetidamente, queimando o orçamento de redução.
Um script que reduz a capacidade com frequência demais — muitas pequenas reduções em vez de uma maior.
Ajuste manual durante testes de carga — reduzir a capacidade repetidamente conforme o tráfego diminui.
Orçamentos por índice — os limites de redução de tabela e GSI são desacoplados, então cada GSI tem sua própria cota; uma tabela com vários índices pode atingi-lo em um deles. Uma única requisição UpdateTable que reduz tanto a tabela quanto um GSI é rejeitada inteira se qualquer um exceder seu limite atual.

Como corrigir

Espere a recarga. Uma redução fica disponível a cada hora (até 4 disponíveis a qualquer momento); um orçamento novo de 4 reduções começa a cada dia UTC.
Faça menos reduções, maiores. Caia de 1000 → 200 em um passo em vez de cinco passos de 160 unidades.
Ajuste o auto-scaling — eleve a utilização alvo e adicione um cooldown de scale-in para que ele pare de reduzir tão agressivamente.
Mude para on-demand se a carga é de rajada ou imprevisível:
```
aws dynamodb update-table --table-name <Table> \
  --billing-mode PAY_PER_REQUEST
```
O on-demand remove o gerenciamento manual de capacidade (e sua quota de redução) inteiramente.

Erros relacionados

ProvisionedThroughputExceededException — o throttle de runtime quando leituras/escritas excedem a capacidade provisionada.
LimitExceededException — a família mais ampla de quota de control-plane de conta/tabela.
Aprenda: On-demand vs provisioned

Referências

Verificado pela última vez em 2026-07-13 contra a documentação oficial da AWS vinculada acima.