Las reducciones de rendimiento aprovisionado están limitadas dentro de un mismo día

TL;DR — DynamoDB limita con qué frecuencia puedes reducir la capacidad aprovisionada de lectura/escritura de una tabla (o de un GSI) en un solo día UTC. Has agotado el margen, así que se rechaza UpdateTable. Espera al reabastecimiento por hora, agrupa tu reducción en menos pasos más grandes, o cambia la tabla a bajo demanda y deja de gestionar reducciones por completo.

Qué significa

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

Cada tabla empieza un día UTC con un pequeño presupuesto de reducciones de capacidad (los aumentos se pueden hacer tantas veces como sea necesario, sujeto a las cuotas de la cuenta y a que DynamoDB no te deje escalar hacia arriba demasiado rápido). Empiezas el día con 4 reducciones disponibles y ganas 1 más cada hora hasta un máximo de 4 disponibles en cualquier momento — suficiente para hasta 27 reducciones a lo largo de un día completo de 24 horas. Agótalo y las siguientes llamadas de reducción con UpdateTable fallan con un LimitExceededException (HTTP 400; el mensaje genérico de la guía del desarrollador para esta excepción es "Too many operations for a given subscriber.") hasta que el presupuesto se reabastece. Es una cuota, así que reintentar a ciegas no ayudará dentro de la misma ventana.

Por qué ocurre

Oscilación del auto-escalado — una carga de trabajo con picos hace que el auto-escalado de DynamoDB baje la capacidad repetidamente, quemando el presupuesto de reducciones.
Un script que baja la capacidad con demasiada frecuencia — muchas reducciones pequeñas en lugar de una más grande.
Ajuste manual durante pruebas de carga — bajando la capacidad repetidamente a medida que el tráfico decae.
Presupuestos por índice — los límites de reducción de la tabla y de los GSI están desacoplados, así que cada GSI tiene su propio margen; una tabla con varios índices puede alcanzarlo en uno de ellos. Una sola petición UpdateTable que reduce tanto la tabla como un GSI se rechaza por completo si cualquiera de los dos supera su límite actual.

Cómo solucionarlo

Espera al reabastecimiento. Cada hora queda disponible una reducción (hasta 4 disponibles en cualquier momento); cada día UTC comienza un nuevo presupuesto de 4 reducciones.
Haz reducciones menos frecuentes y más grandes. Baja de 1000 → 200 en un solo paso en lugar de cinco pasos de 160 unidades.
Ajusta el auto-escalado — sube la utilización objetivo y añade un periodo de enfriamiento (cooldown) de reducción para que deje de bajar de forma tan agresiva.
Cambia a bajo demanda si la carga de trabajo es irregular o impredecible:
```
aws dynamodb update-table --table-name <Table> \
  --billing-mode PAY_PER_REQUEST
```
Bajo demanda elimina la gestión manual de capacidad (y su cuota de reducciones) por completo.

Errores relacionados

ProvisionedThroughputExceededException — la limitación en tiempo de ejecución cuando las lecturas/escrituras superan la capacidad aprovisionada.
LimitExceededException — la familia de cuotas más amplia del plano de control de cuenta/tabla.
Aprende: On-demand vs provisioned

Referencias

Última verificación el 2026-07-13 con la documentación oficial de AWS enlazada arriba.