Capacidad On-Demand vs Provisioned en DynamoDB
DynamoDB factura el rendimiento de dos maneras. On-Demand cobra por petición — pagas por lo que usas, escalando hasta cero. Provisioned reserva una tasa fija de lectura/escritura que pagas la uses o no, a un precio por unidad mucho más bajo. Elegir mal es una de las formas más fáciles de pagar de más.
El registro de auditoría hace la elección concreta. Las escrituras de auditoría son irregulares e impredecibles: tranquilas de madrugada, y luego una avalancha cuando un cliente ejecuta una operación masiva o un incidente genera miles de eventos. Esa forma del tráfico es toda la decisión.
¿Debo usar la capacidad On-Demand o Provisioned de DynamoDB?
On-Demand cobra por petición y escala hasta cero, lo que lo convierte en la opción segura por defecto para tráfico irregular, nuevo o impredecible. Provisioned reserva una tasa fija de lectura/escritura a un precio por unidad mucho más bajo, y solo resulta ventajoso cuando el tráfico es sostenido y constante, manteniendo esa reserva bien aprovechada. Elige On-Demand salvo que tu volumen esté demostrado y sea predecible.
- On-Demand = pago por petición, escala hasta cero. No hay capacidad que planificar; pagas un precio por lectura/escritura más alto, pero solo cuando hay tráfico.
- Provisioned = reserva una tasa constante, la pagas siempre. Mucho más barato por unidad si la tasa está bien aprovechada; comes el coste de la capacidad ociosa.
- Tráfico irregular / desconocido → On-Demand. Tráfico constante, predecible y de alto volumen → Provisioned (opcionalmente con auto-scaling).
- Puedes cambiar de modo, pero solo un número limitado de veces cada 24 horas — no es un interruptor por petición.
El problema: pagar por capacidad que no usas
Con capacidad Provisioned te comprometes, digamos, a 1.000 unidades de escritura por segundo. Si el registro de auditoría promedia 50 escrituras/segundo pero aprovisionaste para el pico del día de incidente, pagas por 1.000 a todas horas y usas una veinteava parte. Aprovisiona para la media en su lugar y la avalancha del día de incidente sufre throttling — se rechazan escrituras.
Así que la capacidad fija obliga a un mal compromiso con el tráfico irregular: pagar de más constantemente, o aprovisionar de menos y perder escrituras cuando más importa. On-Demand existe precisamente para eliminar ese compromiso.
Cómo funcionan los dos modos
On-Demand cobra por las unidades de petición de lectura y escritura que realmente consumes, sin capacidad que configurar — acomoda los picos de tráfico al instante y escala hasta cero cuando está ocioso. Pagas una prima por petición por esa elasticidad.
Provisioned reserva un número de Read Capacity Units (RCU) y Write Capacity Units (WCU) por segundo. El precio por unidad es mucho más bajo, pero pagas la reserva de forma continua, la uses o no. Supérala y DynamoDB aplica throttling salvo que el auto-scaling esté activado para aumentar la capacidad dentro de los límites configurados — aunque el auto-scaling reacciona a lo largo de minutos, así que un pico repentino aún puede sufrir throttling antes de que se ponga al día.
El punto de cruce es el aprovechamiento. A grandes rasgos: si tu tráfico sostenido y predecible mantiene la capacidad Provisioned bien aprovechada, Provisioned gana en precio; si el tráfico es irregular, a ráfagas o desconocido, On-Demand gana al no cobrar por la reserva ociosa.
Un ejemplo práctico: la factura del registro de auditoría
El registro de auditoría escribe ~50 eventos/segundo de media, pero llega a ráfagas de miles durante incidentes, con un tráfico de lectura mucho menor (exportaciones de cumplimiento, alguna investigación ocasional). Cada evento es pequeño — muy por debajo de 1 KB.
En Provisioned, tendrías que reservar para la ráfaga (pagándola 24/7) o arriesgarte a aplicar throttling a la avalancha del día de incidente — el peor momento para perder escrituras de auditoría. En On-Demand, las horas tranquilas cuestan casi nada y la ráfaga se absorbe automáticamente; pagas exactamente por las escrituras que ocurrieron.
Para esta carga de trabajo, On-Demand es el valor por defecto correcto. La regla general: empieza en On-Demand para cualquier tabla nueva o irregular, y pásate a Provisioned solo una vez que el tráfico esté demostrado lo bastante constante como para mantener una reserva aprovechada.
Mete tus propios números — lecturas/escrituras por segundo, tamaño de Item, almacenamiento — para ver los dos modos lado a lado para una región:
Para el panorama multirregión completo con la capa gratuita aplicada, usa la Calculadora de precios de DynamoDB.
Hazlo en DynoTable
La decisión de capacidad parte de números reales: cómo de grandes son los Items, cuántos hay, a qué velocidad se escriben. Adivinar eso es como acaban las tablas mal aprovisionadas.
Para convertir un evento de muestra en las RCU/WCU que realmente consume, ejecútalo en la calculadora de tamaño de Item. Luego fundamenta la decisión en tu tabla real: DynoTable expone sus metadatos — número y tamaño de Items — y te deja inspeccionar Items representativos para que puedas dimensionarlos con precisión.
Trampas y próximos pasos
- Cambiar de modo está limitado por tasa. Puedes cambiar entre On-Demand y Provisioned, pero solo un número limitado de veces cada 24 horas — trátalo como una decisión meditada, no como un dial que giras.
- El auto-scaling no es instantáneo. Reacciona a lo largo de minutos, así que un pico brusco en Provisioned puede sufrir throttling antes de que crezca la capacidad. Para tráfico genuinamente a ráfagas, On-Demand absorbe el pico directamente.
- Una partición caliente sufre throttling sea cual sea el modo. Incluso On-Demand tiene límites por partición — claves desiguales pueden sufrir throttling mientras la tabla parece estar por debajo de su capacidad. Ver particiones calientes.
- Los GSI tienen su propia capacidad. Cada índice se factura por separado y puede aplicar throttling a las escrituras de la tabla base si está mal aprovisionado — ver por qué un GSI aplica throttling a las escrituras de la tabla base.
El modo de capacidad fija lo que pagas por operar la tabla en una región. Lo siguiente: replicarla entre regiones con DynamoDB Global Tables.
Descargar DynoTable para leer el tamaño y el número de Items reales de tu tabla antes de comprometerte con un modo de capacidad.