¿DynamoDB puede escalar automáticamente?
Sí. El escalado automático de DynamoDB usa Application Auto Scaling para ajustar la capacidad de lectura y escritura aprovisionada hacia una utilización objetivo (configurable entre el 20 y el 90%, normalmente el 70%), dentro de los límites mínimo y máximo que definas. Como alternativa, el modo de capacidad bajo demanda escala al instante con el tráfico sin ninguna configuración. Ambos mantienen las tablas receptivas ante una carga cambiante sin planificación manual de capacidad.
Escalado automático en modo aprovisionado
Creas una política de escalado por tabla (y por índice secundario global) que fija:
- una utilización objetivo (porcentaje de la capacidad aprovisionada al que apuntar),
- la capacidad mínima y máxima en unidades, y
- si escalar lecturas, escrituras o ambas.
Las alarmas de CloudWatch activan Application Auto Scaling para subir o bajar la capacidad a medida que el consumo cruza el objetivo.
Modo bajo demanda
La capacidad bajo demanda elimina la planificación por completo: DynamoDB ajusta el rendimiento a tu tráfico por su cuenta — absorbiendo al instante hasta el doble de tu pico de tráfico anterior — y te factura por petición. Encaja bien cuando el tráfico es irregular o difícil de predecir.
Cuál elegir
El modo aprovisionado con escalado automático suele costar menos cuando el tráfico es estable y bien conocido; el modo bajo demanda es más sencillo y mejor para tráfico desconocido o irregular.
Dónde deja de compensar la utilización objetivo
La utilización objetivo es un dial de precio, y tiene un suelo por debajo del cual el escalado automático pierde de plano frente al modo bajo demanda.
En us-east-1 una unidad de capacidad de escritura cuesta 0,00065 $ la hora, así que reservar una durante un mes cuesta 0,4745 $ y compra 2.628.000 escrituras. Eso son 0,00000018 $ por escritura frente a los 0,000000625 $ del modo bajo demanda, lo que hace la capacidad aprovisionada 3,46 veces más barata cuando se usa cada unidad reservada. Dale la vuelta y obtienes el punto de equilibrio: el modo aprovisionado deja de compensar por debajo del 28,9% de utilización media. Las lecturas dan ese mismo 28,9%, así que esto es una propiedad del modelo de precios y no de una tarifa concreta.
Con 1.000 escrituras por segundo sostenidas de Items de 1 KB, calculado con la calculadora de precios:
| Ajuste de capacidad | Aprovisionada | Mensual |
|---|---|---|
| Objetivo del 90% | 1.112 WCU | 527,64 $ |
| Objetivo del 70% | 1.429 WCU | 678,06 $ |
| Objetivo del 50% | 2.000 WCU | 949,00 $ |
| Objetivo del 20% | 5.000 WCU | 2.372,50 $ |
| Bajo demanda | ninguna | 1.642,50 $ |
Las dos últimas filas llevan la lección. Un objetivo del 20%, el más bajo que acepta AWS, reserva cinco veces tu tráfico y cuesta un 44% más que pagar por petición por el mismo trabajo. Cada fila de arriba asume que el escalado automático clava la capacidad exactamente en el objetivo, así que tómalas como el mejor caso: el tráfico real serpentea y el algoritmo lo sigue tarde, lo que arrastra la utilización real por debajo de la que hayas configurado.
Qué compra el dial
Escalar hacia arriba y hacia abajo es deliberadamente asimétrico, y esa asimetría es lo que paga el margen. AWS documenta que el escalado hacia arriba se dispara después de que la capacidad consumida supere el objetivo durante dos minutos consecutivos, y el escalado hacia abajo tras 15 puntos de datos consecutivos por debajo. La llamada UpdateTable que viene después tarda varios minutos más, y todo lo que supere el techo anterior se limita mientras tanto.
Las bajadas también están racionadas. Empiezas cada día UTC con cuatro y ganas una por hora, sin acumular nunca más de cuatro, lo que te deja un tope de 27 al día por tabla. Los índices secundarios globales tienen su propia asignación.
Así que un objetivo alto ahorra dinero de verdad y gasta el colchón que cubre esos minutos. El modo bajo demanda cuesta más por petición y elimina el intercambio por completo.
Profundiza
Compáralos en capacidad bajo demanda frente a aprovisionada y estima el coste con la calculadora de precios. Descarga DynoTable para leer el tamaño de una tabla y sus estimaciones de elementos en Estadísticas de tabla.
Referencias
- Managing throughput capacity automatically with DynamoDB auto scaling — Amazon DynamoDB Developer Guide
- DynamoDB on-demand capacity mode — Amazon DynamoDB Developer Guide
- DynamoDB provisioned capacity mode — Amazon DynamoDB Developer Guide
- Quotas in Amazon DynamoDB — Amazon DynamoDB Developer Guide — la asignación de bajadas, re-verificada el 2026-07-28.
Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.
Punto de equilibrio calculado el 2026-07-28 con nuestra propia calculadora de precios sobre las tarifas de us-east-1 que sincroniza desde la API de lista de precios de AWS. Los retardos de escalado y la asignación de bajadas se releyeron de la documentación de AWS enlazada arriba en la misma fecha.