DynamoDB: bajo demanda vs aprovisionada
DynamoDB factura el rendimiento de dos formas. Bajo demanda cobra por petición — pagas por lo que usas, escalando hasta cero. Aprovisionada reserva una tasa fija de lectura/escritura que pagas la uses o no, a un precio por unidad mucho más bajo. Escoger el modo equivocado es una de las maneras más fáciles de pagar de más.
El registro de auditoría hace concreta la decisión. Las escrituras de auditoría son irregulares e impredecibles: tranquilas de noche, 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 la decisión entera.
¿Debería usar capacidad bajo demanda o aprovisionada en DynamoDB?
Bajo demanda cobra por petición y escala hasta cero, lo que la convierte en el valor por defecto seguro para tráfico irregular, nuevo o impredecible. Aprovisionada reserva una tasa fija de lectura/escritura a un precio por unidad mucho más bajo, y solo gana cuando un tráfico sostenido y constante mantiene esa reserva bien aprovechada. Escoge bajo demanda salvo que tu volumen esté demostrado y sea predecible.
- Bajo demanda = pago por petición, escala hasta cero. Sin capacidad que planificar; pagas un precio más alto por lectura/escritura, pero solo cuando ocurre el tráfico.
- Aprovisionada = reservas una tasa constante, la pagas siempre. Mucho más barata por unidad si la tasa está bien aprovechada; te comes el coste de la capacidad ociosa.
- El tráfico irregular o desconocido pide bajo demanda. El tráfico constante, predecible y de gran volumen pide aprovisionada (opcionalmente con escalado automático).
- Puedes cambiar de modo, pero el límite es asimétrico: de aprovisionada a bajo demanda está limitado a cuatro veces por cada 24 horas, mientras que de bajo demanda a aprovisionada es ilimitado — no es un conmutador por petición.
El problema: pagar por capacidad que no usas
Con capacidad aprovisionada te comprometes, digamos, a 1000 unidades de escritura por segundo. Si el registro de auditoría promedia 50 escrituras/segundo pero aprovisionaste para el pico del día del incidente, pagas por 1000 a todas horas y usas una veinteava parte. Aprovisiona para el promedio en su lugar y la avalancha del día del incidente limita el tráfico — las escrituras se rechazan.
Así que la capacidad fija fuerza un mal trato con el tráfico irregular: pagar de más constantemente, o aprovisionar de menos y perder escrituras cuando más importa. Bajo demanda existe precisamente para eliminar ese trato.
Cómo funcionan los dos modos
Bajo demanda cobra por las unidades de petición de lectura y escritura que realmente consumes, sin capacidad que configurar — acomoda de inmediato los picos hasta el doble de tu pico de tráfico previo y escala hasta cero cuando está inactiva. Más allá de ese salto de 2x en una ventana corta puede aún limitar el tráfico mientras se acelera. Pagas una prima por petición por esa elasticidad.
Aprovisionada reserva un número de unidades de capacidad de lectura (RCU) y unidades de capacidad de escritura (WCU) por segundo. El precio por unidad es mucho más bajo, pero pagas por la reserva continuamente, se use o no. Supérala y DynamoDB limita el tráfico salvo que el escalado automático esté activado para hacer crecer la capacidad dentro de los límites configurados — aunque el escalado automático reacciona a lo largo de minutos, así que un pico repentino puede aun así limitar el tráfico 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 aprovisionada bien aprovechada, aprovisionada gana en precio; si el tráfico es irregular, con ráfagas o desconocido, bajo demanda gana al no cobrar por la reserva ociosa.
Un ejemplo resuelto: la factura del registro de auditoría
El registro de auditoría escribe ~50 eventos/segundo de media, pero estalla hasta miles durante incidentes, con un tráfico de lectura mucho menor (exportaciones de cumplimiento, la investigación ocasional). Cada evento es pequeño — muy por debajo de 1 KB.
En aprovisionada, tendrías que reservar para la ráfaga (pagándola 24/7) o arriesgarte a limitar la avalancha del día del incidente — el peor momento para descartar escrituras de auditoría. En bajo demanda, las horas tranquilas cuestan casi nada y una ráfaga de hasta el doble del pico reciente se absorbe sin configuración; pagas exactamente por las escrituras que ocurrieron.
Para esta carga de trabajo, bajo demanda es el valor por defecto correcto. La regla general: empieza en bajo demanda para cualquier tabla nueva o irregular, y pásate a aprovisionada solo una vez que el tráfico esté demostrado lo bastante constante como para mantener una reserva aprovechada.
Introduce tus propios números — lecturas/escrituras por segundo, tamaño de elemento, almacenamiento — para ver los dos modos uno junto al otro 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 elementos, cuántos hay, con qué rapidez se están escribiendo. Adivinarlos es cómo las tablas acaban mal aprovisionadas.
Para convertir un evento de muestra en las RCU/WCU que realmente consume, pásalo por la calculadora de tamaño de elemento. Luego fundamenta la decisión en tu tabla real: DynoTable muestra sus metadatos — recuento y tamaño de elementos — y te deja inspeccionar elementos representativos para poder dimensionarlos con precisión.
Escollos y próximos pasos
- Cambiar de modo tiene un límite de tasa, y asimétrico. De aprovisionada a bajo demanda está limitado a cuatro cambios por cada 24 horas; de bajo demanda a aprovisionada es ilimitado. Trátalo como una decisión meditada, no como un dial que giras.
- El escalado automático no es instantáneo. Reacciona a lo largo de minutos, así que un pico brusco en aprovisionada puede limitar el tráfico antes de que crezca la capacidad. Para tráfico genuinamente irregular, bajo demanda gestiona mejor el pico — hasta el doble de tu pico previo al instante. Si sabes que un pico superará eso (un lanzamiento o una rebaja), configura de antemano el rendimiento en caliente en la tabla para preaprovisionar el margen de la ráfaga.
- Una partición caliente limita el tráfico independientemente del modo. Incluso bajo demanda tiene límites por partición — claves desiguales pueden limitar el tráfico mientras la tabla parece por debajo de su capacidad. Mira particiones calientes.
- Los tienen su propia capacidad. Cada índice se factura por separado y puede limitar las escrituras de la tabla base si está infraaprovisionado — mira por qué un GSI limita las escrituras de la tabla base.
El modo de capacidad fija lo que pagas por ejecutar la tabla en una región. Siguiente: replicarla entre regiones con Tablas Globales de DynamoDB.
Descarga DynoTable para leer el tamaño y el recuento de elementos reales de tu tabla antes de comprometerte con un modo de capacidad.