DynamoDB throttled en una partición activa a pesar de la capacidad

TL;DR: Su tabla tiene muchos RCU/WCU en general, pero aún está agotado porque una única clave de partición está activa. Cada partición física está diseñada para ofrecer un máximo de 3000 unidades de lectura y 1000 unidades de escritura por segundo, independientemente de la capacidad que tenga la tabla. El tráfico acumulado en una clave agota esa partición. Distribuya las solicitudes entre claves de partición más distintas (fragmentación de escritura) para solucionarlo.

Qué 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.

DynamoDB reparte una tabla entre muchas particiones físicas, y la capacidad de una tabla se divide entre ellas. Una partición individual está diseñada para entregar como máximo 3.000 unidades de lectura y 1.000 unidades de escritura por segundo — en ambos modos de capacidad. Si tu patrón de acceso concentra el tráfico en una clave de partición, la partición de esa clave alcanza su propio techo y se throttlea — aunque las métricas de toda la tabla parezcan infrautilizadas (los campos ThrottlingReason del error, p. ej. TableReadKeyRangeThroughputExceeded, nombran el límite exacto que se alcanzó). La capacidad adaptativa ayuda, pero no puede rescatar una clave genuinamente desequilibrada.

Por qué ocurre

• Clave de partición de baja cardinalidad — un indicador de estado, un booleano, una "fecha actual" o un único tenant que recibe la mayoría del tráfico.
• Un Item viral / de celebridad — una clave de partición popular (un producto en tendencia, un usuario caliente) atrae una carga desproporcionada.
• Series temporales con una clave "de hoy" — cada escritura aterriza en la misma clave de partición basada en la fecha.
• Una clave secuencial o monótona de modo que las escrituras se agrupan en la partición más reciente.
• Un GSI con una clave de partición de baja cardinalidad, que throttlea las escrituras de la tabla base.

Cómo solucionarlo

1. Aumenta la cardinalidad de la clave. Diseña la clave de partición para que las solicitudes se repartan entre muchos valores — esta es la solución más eficaz.
2. Aplica write-sharding a la clave caliente. Añade un sufijo (USER#42#1…USER#42#N) para que una entidad lógica abarque varias particiones; distribuye las lecturas entre los shards.
3. Añade aleatoriedad o un sufijo calculado a las claves de series temporales para que las escrituras "de hoy" no colisionen todas.
4. Cachea las lecturas calientes (DAX o una caché de aplicación) para descargar presión de lectura de la partición caliente.
5. Mantén los reintentos con retroceso exponencial — este error es reintentable y el SDK retrocede por defecto.
6. Arregla las claves de GSI de baja cardinalidad — un GSI throttleado throttlea la tabla base.
7. Consulta ThrottlingReason en el error. Indica si el límite alcanzado fue el de toda la tabla o el de un rango de claves concreto.

Mide el tamaño en DynoTable

Encuentra la clave de partición caliente — abre la tabla con ⌘K, ordena por clave de partición y busca una clave que cargue con muchos más Items que sus vecinas. Filtra por esa clave e inspecciona los patrones de escritura antes de volver a fragmentar.

Modela los sufijos de write-sharding en el Query Builder y estima el tráfico de reintentos con la calculadora de precios. Cambia de perfil con ⌘P; consulta Conectar con AWS e Instalación.

Fuentes

• Best practices for designing partition keys (verificado 2026-07-13)
• Troubleshooting throttling in Amazon DynamoDB (verificado 2026-07-13)

FAQ

¿Por qué me throttlea DynamoDB cuando la tabla tiene capacidad de sobra? Porque una única clave de partición está caliente. Cada partición física tiene un techo de unas 3.000 unidades de lectura y 1.000 unidades de escritura por segundo independientemente de la capacidad a nivel de tabla, así que el tráfico acumulado sobre una clave agota esa única partición mientras las métricas de toda la tabla parecen infrautilizadas.

¿Cómo arreglo una partición caliente en DynamoDB? Aumenta la cardinalidad de la clave de partición para que las solicitudes se repartan entre muchos valores, aplica write-sharding a la clave caliente con un sufijo, añade un sufijo calculado a las claves de series temporales y cachea las lecturas calientes. Los reintentos con retroceso exponencial ayudan a sobrellevar picos cortos pero no arreglan una clave desequilibrada.

Errores relacionados

• ProvisionedThroughputExceededException — el error de throttling general y las soluciones de capacidad.
• ThrottlingException — límites de tasa de cuenta / plano de control.
• Aprende: Hot partitions · How partition keys work

Referencias

• Best practices for designing and using partition keys effectively in DynamoDB — Amazon DynamoDB Developer Guide
• Using write sharding to distribute workloads evenly in your DynamoDB table — Amazon DynamoDB Developer Guide
• Troubleshooting throttling in Amazon DynamoDB — Amazon DynamoDB Developer Guide
• Error handling with DynamoDB — Amazon DynamoDB Developer Guide

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