DynamoDB ProvisionedThroughputExceededException

TL;DR — Estás leyendo/escribiendo más rápido de lo que la tabla o el índice puede servir. Cambia la tabla a capacidad bajo demanda, sube las RCU/WCU aprovisionadas (o activa el auto-escalado), mantén los reintentos con backoff exponencial por defecto del SDK, y distribuye el tráfico para que una clave de partición no se caliente.

Qué significa

ProvisionedThroughputExceededException: You exceeded your maximum allowed
provisioned throughput for a table or for one or more global secondary indexes.

En una tabla de capacidad aprovisionada, has superado las unidades de capacidad de lectura/escritura — ya sea en conjunto, o (más a menudo) en una única partición. Es un HTTP 400 pero, a diferencia de un ValidationException, sí es reintentable: los SDK de AWS lo reintentan automáticamente con backoff exponencial, así que los casos ocasionales son normales. Los persistentes indican una infra-provisión real o una clave caliente. El error incluye campos ThrottlingReason (p. ej. TableReadProvisionedThroughputExceeded) más el ARN del recurso afectado, para que puedas saber qué tabla o índice sufrió la limitación y en qué tipo de operación.

Por qué ocurre

Capacidad infra-aprovisionada para el tráfico real.
Una partición caliente — tráfico concentrado en una clave de partición, de modo que la parte de capacidad de una única partición se agota mientras la tabla parece infrautilizada en conjunto.
Tráfico con picos más rápido de lo que el auto-escalado puede reaccionar — este ajusta la capacidad en respuesta a las métricas de capacidad consumida, así que un cambio brusco en escalón provoca limitaciones antes de que aterrice el escalado hacia arriba.
Un escaneo grande o una importación masiva consumiendo toda la capacidad de golpe.
Un GSI cuya capacidad es menor que la tasa de escritura — un GSI limitado limita la tabla base.

Cómo solucionarlo

Cambia a capacidad bajo demanda si el tráfico es impredecible — escala automáticamente y este error desaparece en la práctica (pagas por petición en su lugar).
Sube las RCU/WCU aprovisionadas o activa el auto-escalado con una utilización objetivo razonable si te quedas en aprovisionado.
Mantén los reintentos con backoff exponencial — el SDK lo hace por defecto; no lo desactives. Usa el modo de reintento adaptativo para cargas con picos.
Arregla la partición caliente — aumenta la cardinalidad de la clave / reparte por escritura la clave caliente para que la carga se distribuya entre particiones.
Limita los trabajos masivos y cachea las lecturas calientes (DAX o una caché de aplicación) para aliviar la presión de lectura.

FAQ

¿Cómo soluciono ProvisionedThroughputExceededException? Estás leyendo o escribiendo más rápido de lo que la tabla o el índice puede servir. Cambia la tabla a capacidad bajo demanda, sube las RCU/WCU aprovisionadas (o activa el auto-escalado), mantén los reintentos con backoff exponencial por defecto del SDK, y distribuye el tráfico para que una única clave de partición no se caliente.

Reproducirlo

Aprovisiona una tabla a 1 RCU, escribe un item justo por debajo de 4 KB y luego léelo con consistencia fuerte en un bucle cerrado:

import boto3
ddb = boto3.client('dynamodb', region_name='us-east-1')
# table created with ProvisionedThroughput={'ReadCapacityUnits': 1, 'WriteCapacityUnits': 1}
ddb.put_item(TableName='my-table', Item={'pk': {'S': 'A'}, 'blob': {'S': 'x' * 3500}})
while True:
    ddb.get_item(TableName='my-table', Key={'pk': {'S': 'A'}}, ConsistentRead=True)

Salida real:

ProvisionedThroughputExceededException: The level of configured provisioned throughput for the table was exceeded. Consider increasing your provisioning level with the UpdateTable API.
HTTP 400

Hicieron falta 49 lecturas para provocarlo, sobre una tabla recién creada y con los reintentos del SDK desactivados. Ese número es la parte interesante: una tabla de 1 RCU no falla en la segunda petición, porque DynamoDB te presta primero la capacidad de ráfaga acumulada — así que una prueba de carga que se detenga pronto dará por sana una tabla que no lo está. La otra mitad de la ilusión es el SDK, que por defecto reintenta por ti las peticiones limitadas; desactiva los reintentos como arriba, o este error seguirá invisible hasta que sea un problema de latencia.

Errores relacionados

ThrottlingException — límites de tasa de cuenta/plano de control.
Throttled despite spare capacity (hot partition) — una clave de partición acaparando el tráfico.
On-demand throughput exceeded — el equivalente en modo bajo demanda.
ItemCollectionSizeLimitExceededException
Ejemplo de código: BatchWriteItem in Node.js — el patrón de reintento con backoff de UnprocessedItems.
Aprende: On-demand vs provisioned · Hot partitions

Referencias

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.

Reproducido el 2026-07-26 contra el servicio DynamoDB en vivo en us-east-1 mediante boto3 1.43.56, sobre una tabla aprovisionada a 1 RCU y con los reintentos del SDK desactivados — la salida de arriba es literal.