Modos de Capacidad en DynamoDB: ¿Provisionado o Bajo Demanda?

Cuando lanzas una nueva aplicación en AWS y aún no tienes datos históricos de tráfico, elegir el modo de capacidad incorrecto en DynamoDB puede resultar en throttling inesperado o en facturas que no esperabas. Esta guía cubre los modos de capacidad de DynamoDB desde una perspectiva operacional real: cuándo cada uno tiene sentido, cómo migrar entre ellos, y cómo evitar los errores más comunes.

TL;DR — Guía de Decisión Rápida

Si no conoces tus patrones de tráfico todavía, empieza con On-Demand (Bajo Demanda). Migra a Provisionado con Auto Scaling cuando tengas al menos 2-4 semanas de métricas reales de consumo.

CriterioOn-DemandProvisionado + Auto Scaling
Tráfico predecibleNo óptimoRecomendado
Tráfico impredecible o spikyRecomendadoRiesgo de throttling
Fase de desarrollo / MVPRecomendadoSobreingeniería temprana
Costo por millón de solicitudesMayor por unidadMenor si se utiliza bien
Configuración operacionalCeroRequiere tuning de políticas

Cómo Funcionan los Modos de Capacidad de DynamoDB

DynamoDB mide el throughput en unidades de capacidad de lectura (RCU) y escritura (WCU). Una RCU cubre una lectura fuertemente consistente de hasta 4 KB, y una WCU cubre una escritura de hasta 1 KB. Todo lo que exceda esas unidades disponibles genera un error ProvisionedThroughputExceededException — lo que los operadores llaman throttling.

graph TD A["Solicitud de la Aplicación"] --> B["DynamoDB: Evaluar Modo"] B --> C{"¿Modo Activo?"} C -->|"On-Demand"| D["AWS gestiona capacidad
automáticamente"] C -->|"Provisionado"| E{"¿Hay RCU/WCU
disponibles?"} D --> F["Solicitud Procesada"] E -->|"Sí"| F E -->|"No"| G["ThrottlingException"] E -->|"Consumo alto"| H["CloudWatch detecta
utilización elevada"] H --> I["Auto Scaling ajusta
capacidad (minutos)"] I --> E
  1. Solicitud de lectura/escritura: La aplicación envía una operación a DynamoDB.
  2. Token Bucket: DynamoDB evalúa si hay capacidad disponible en el bucket de tokens del modo activo.
  3. On-Demand: AWS gestiona automáticamente la capacidad; la solicitud se procesa sin configuración previa.
  4. Provisionado: Si hay RCU/WCU disponibles, la solicitud pasa. Si no, se genera throttling.
  5. Auto Scaling (Provisionado): CloudWatch detecta el consumo elevado y ajusta los límites provisionados, pero con latencia de minutos — no de milisegundos.
Auto Scaling en modo Provisionado no es instantáneo. Funciona como un termostato que ajusta la calefacción después de que ya sientes frío — útil para tendencias, inútil para picos abruptos de segundos.

Modo On-Demand: Cuándo Usarlo

On-Demand elimina completamente la gestión de capacidad. DynamoDB escala automáticamente para manejar cualquier volumen de tráfico sin que configures nada. El costo se calcula por solicitud consumida.

Este modo es la elección correcta cuando:

  • Estás en fase de MVP o prototipo y no tienes datos históricos de tráfico.
  • Tu aplicación tiene picos de tráfico impredecibles — lanzamientos de productos, campañas virales, eventos en tiempo real.
  • El costo operacional de gestionar políticas de Auto Scaling supera el ahorro potencial.
  • Prefieres cero riesgo de throttling sobre optimización de costos.

La limitación real de On-Demand no es el costo por unidad — es que tiene un límite de throughput máximo por tabla que AWS puede ajustar bajo solicitud. Para cargas de trabajo con volúmenes extremadamente altos y predecibles, Provisionado termina siendo más económico.

Modo Provisionado con Auto Scaling: Cuándo Usarlo

En modo Provisionado, defines explícitamente cuántas RCU y WCU quieres reservar. Auto Scaling de DynamoDB usa políticas de Application Auto Scaling para ajustar esos valores dentro de un rango mínimo y máximo que tú configuras, basándose en el porcentaje de utilización objetivo.

graph LR A["Tráfico de la App"] --> B["DynamoDB Provisionado"] B --> C["CloudWatch Metrics
RCU/WCU cada minuto"] C --> D["Application Auto Scaling"] D -->|"Utilización > objetivo"| E["Aumentar capacidad
provisionada"] D -->|"Utilización < objetivo"| F["Reducir capacidad
provisionada"] E --> B F --> B B -->|"Capacidad insuficiente
durante el gap"| G["Throttling temporal"]
  1. Configuración inicial: Defines mínimo, máximo y objetivo de utilización (típicamente 70%).
  2. Monitoreo continuo: CloudWatch publica métricas de consumo de RCU/WCU cada minuto.
  3. Decisión de escala: Application Auto Scaling evalúa si el consumo supera o baja del objetivo.
  4. Ajuste de capacidad: DynamoDB actualiza los valores provisionados — este proceso toma minutos, no segundos.
  5. Throttling en el gap: Si el tráfico sube más rápido que el ciclo de Auto Scaling, ocurre throttling durante ese intervalo.

Este modo tiene sentido cuando tienes al menos varias semanas de métricas reales que muestran un patrón de crecimiento gradual y predecible. La combinación de Provisionado + Auto Scaling bien configurada es significativamente más económica que On-Demand para cargas de trabajo estables de alto volumen.

Comparación Técnica Detallada de los Modos de Capacidad

CaracterísticaOn-DemandProvisionado
Gestión de capacidadAutomática (AWS)Manual o Auto Scaling
Riesgo de throttlingMuy bajoPresente si mal configurado
Modelo de costoPor solicitud consumidaPor capacidad reservada por hora
Ideal paraTráfico variable / desconocidoTráfico predecible y estable
Tiempo de escalaInstantáneoMinutos (vía Auto Scaling)
Configuración requeridaNingunaPolíticas de Auto Scaling
Reserved CapacityNo compatibleCompatible (ahorro adicional)

Guía de Decisión: ¿Qué Modo Elegir?

graph TD START(["¿Qué modo elegir?"]) --> Q1{"¿Tienes datos históricos
de tráfico (2+ semanas)?"} Q1 -->|"No"| OD["✅ On-Demand
(PAY_PER_REQUEST)"] Q1 -->|"Sí"| Q2{"¿El tráfico es
predecible y estable?"} Q2 -->|"No — picos abruptos"| OD Q2 -->|"Sí — crecimiento gradual"| Q3{"¿Alto volumen
de solicitudes?"} Q3 -->|"Bajo/Medio"| OD Q3 -->|"Alto y sostenido"| PROV["✅ Provisionado
+ Auto Scaling"] PROV --> NOTE1["Configura min/max
y objetivo de utilización"] OD --> NOTE2["Monitorea consumo
2-4 semanas"]

Cómo Crear una Tabla DynamoDB con Cada Modo

Crear tabla en modo On-Demand

aws dynamodb create-table \
  --table-name mi-tabla-ondemand \
  --attribute-definitions AttributeName=PK,AttributeType=S \
  --key-schema AttributeName=PK,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --region us-east-1

Crear tabla en modo Provisionado

aws dynamodb create-table \
  --table-name mi-tabla-provisionada \
  --attribute-definitions AttributeName=PK,AttributeType=S \
  --key-schema AttributeName=PK,KeyType=HASH \
  --billing-mode PROVISIONED \
  --provisioned-throughput ReadCapacityUnits=100,WriteCapacityUnits=50 \
  --region us-east-1

Configurar Auto Scaling para una tabla Provisionada

🔽 Ver comandos de Auto Scaling (click para expandir) 
# Registrar la tabla como objetivo escalable (escritura)
aws application-autoscaling register-scalable-target \
  --service-namespace dynamodb \
  --resource-id "table/mi-tabla-provisionada" \
  --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
  --min-capacity 10 \
  --max-capacity 500 \
  --region us-east-1

# Registrar la tabla como objetivo escalable (lectura)
aws application-autoscaling register-scalable-target \
  --service-namespace dynamodb \
  --resource-id "table/mi-tabla-provisionada" \
  --scalable-dimension "dynamodb:table:ReadCapacityUnits" \
  --min-capacity 10 \
  --max-capacity 1000 \
  --region us-east-1

# Crear política de escalado para escritura (objetivo: 70% de utilización)
aws application-autoscaling put-scaling-policy \
  --service-namespace dynamodb \
  --resource-id "table/mi-tabla-provisionada" \
  --scalable-dimension "dynamodb:table:WriteCapacityUnits" \
  --policy-name "WriteAutoScalingPolicy" \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration \
    '{"TargetValue": 70.0, "PredefinedMetricSpecification": {"PredefinedMetricType": "DynamoDBWriteCapacityUtilization"}}' \
  --region us-east-1

Cómo Migrar Entre Modos de Capacidad de DynamoDB

Puedes cambiar el modo de capacidad de una tabla existente en cualquier momento. AWS documenta la siguiente regla sobre la frecuencia de cambios: puedes cambiar entre modos una vez cada 24 horas, con la excepción de que si cambias una tabla de modo Provisionado a On-Demand, puedes volver a cambiarla a modo Provisionado dentro del mismo período de 24 horas.

Migrar de Provisionado a On-Demand

aws dynamodb update-table \
  --table-name mi-tabla-provisionada \
  --billing-mode PAY_PER_REQUEST \
  --region us-east-1

Migrar de On-Demand a Provisionado

aws dynamodb update-table \
  --table-name mi-tabla-ondemand \
  --billing-mode PROVISIONED \
  --provisioned-throughput ReadCapacityUnits=100,WriteCapacityUnits=50 \
  --region us-east-1

Verificar el modo de capacidad actual de una tabla

aws dynamodb describe-table \
  --table-name mi-tabla-ondemand \
  --query 'Table.BillingModeSummary' \
  --region us-east-1

Permisos IAM Mínimos para Gestionar Modos de Capacidad

Para que una aplicación o rol de CI/CD pueda consultar y modificar el modo de capacidad de una tabla, necesita al menos estos permisos. Nota: dynamodb:DescribeTable y dynamodb:UpdateTable soportan restricción por ARN de recurso.

🔽 Ver política IAM (click para expandir) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeTableCapacity",
      "Effect": "Allow",
      "Action": [
        "dynamodb:DescribeTable"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/mi-tabla-ondemand"
    },
    {
      "Sid": "UpdateTableCapacityMode",
      "Effect": "Allow",
      "Action": [
        "dynamodb:UpdateTable"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/mi-tabla-ondemand"
    },
    {
      "Sid": "AutoScalingRegistration",
      "Effect": "Allow",
      "Action": [
        "application-autoscaling:RegisterScalableTarget",
        "application-autoscaling:PutScalingPolicy",
        "application-autoscaling:DescribeScalableTargets",
        "application-autoscaling:DescribeScalingPolicies"
      ],
      "Resource": "*"
    }
  ]
}

Diagnóstico: Throttling en DynamoDB — Síntoma, Diagnóstico Erróneo y Causa Real

El escenario clásico: tienes Auto Scaling configurado, las métricas de CloudWatch muestran que la utilización promedio está al 60%, y aun así aparecen errores ProvisionedThroughputExceededException en los logs. El diagnóstico inicial suele ser 'el límite provisionado es insuficiente' — y la respuesta instintiva es subir las WCU manualmente.

El problema real casi siempre es una distribución desigual de acceso a particiones — lo que DynamoDB llama 'hot partitions'. DynamoDB distribuye el throughput provisionado entre las particiones de la tabla. Si el 80% de tus escrituras van a la misma clave de partición, esa partición específica se satura aunque el throughput agregado de la tabla esté por debajo del límite.

Subir las WCU totales no resuelve el problema — solo lo enmascara temporalmente. La solución correcta es revisar el diseño de la clave de partición para distribuir el acceso uniformemente.

Verificar throttling por tabla y partición

# Ver eventos de throttling recientes en CloudWatch
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name WriteThrottleEvents \
  --dimensions Name=TableName,Value=mi-tabla-provisionada \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-01T01:00:00Z \
  --period 300 \
  --statistics Sum \
  --region us-east-1

Si ves throttling con utilización agregada baja, el problema es de distribución de particiones — no de capacidad total. Cambiar a On-Demand no resuelve hot partitions; solo cambia el modelo de cobro del problema.

Monitoreo de Consumo de Capacidad con CloudWatch

Independientemente del modo elegido, estas métricas son las que debes monitorear activamente para tomar decisiones de migración entre modos.

# Consumo de WCU en los últimos 60 minutos (resolución de 1 minuto)
aws cloudwatch get-metric-statistics \
  --namespace AWS/DynamoDB \
  --metric-name ConsumedWriteCapacityUnits \
  --dimensions Name=TableName,Value=mi-tabla-ondemand \
  --start-time 2024-01-01T00:00:00Z \
  --end-time 2024-01-01T01:00:00Z \
  --period 60 \
  --statistics Sum \
  --region us-east-1

Cuando el consumo promedio de On-Demand sea estable durante 2-4 semanas sin picos abruptos, tienes suficiente información para calcular si Provisionado + Auto Scaling sería más económico para tu carga de trabajo específica.

Modos de Capacidad de DynamoDB: Próximos Pasos

Si estás comenzando sin datos de tráfico, la decisión correcta es On-Demand. No es la más económica a largo plazo, pero es la que evita throttling mientras acumulas métricas reales. Una vez que tengas 2-4 semanas de datos de ConsumedReadCapacityUnits y ConsumedWriteCapacityUnits, puedes evaluar si la migración a Provisionado con Auto Scaling justifica el ahorro.

  • Consulta la documentación oficial de modos de capacidad de DynamoDB para detalles actualizados sobre límites y precios.
  • Revisa las métricas de WriteThrottleEvents y ReadThrottleEvents en CloudWatch antes de cualquier migración.
  • Si migras a Provisionado, configura siempre Auto Scaling — nunca dejes capacidad fija sin ajuste automático en producción.

Glosario de Términos Clave

TérminoDefinición
RCU (Read Capacity Unit)Unidad que representa una lectura fuertemente consistente de hasta 4 KB, o dos lecturas eventualmente consistentes del mismo tamaño.
WCU (Write Capacity Unit)Unidad que representa una escritura estándar de hasta 1 KB en DynamoDB.
ThrottlingRechazo de solicitudes por DynamoDB cuando el throughput consumido supera la capacidad disponible. Genera el error ProvisionedThroughputExceededException.
Hot PartitionPartición de DynamoDB que recibe una proporción desproporcionada del tráfico, causando throttling localizado aunque el throughput agregado sea suficiente.
PAY_PER_REQUESTValor del parámetro --billing-mode en la CLI de AWS que activa el modo On-Demand en una tabla DynamoDB.

Comentarios

Publicar un comentario

Entradas populares de este blog

EC2 sin acceso a Internet en VPC personalizada: Internet Gateway y Route Table

Creaste una VPC personalizada, lanzaste una instancia EC2 en una subred pública y no puedes hacer ping a google.com — ni SSH funciona desde fuera. Este es uno de los problemas más frecuentes al trabajar con redes en AWS, y casi siempre se reduce a tres capas que deben estar alineadas: el Internet Gateway, la Route Table y la configuración de IP pública. Si falla cualquiera de las tres, el tráfico no sale. TL;DR — Acceso a Internet en EC2 dentro de VPC personalizada Capa Qué debe estar configurado Error típico Internet Gateway Creado y adjunto a la VPC IGW existe pero no está adjunto Route Table Ruta 0.0.0.0/0 apuntando al IGW Route Table sin ruta de salida Subred pública Asociada a la Route Table correcta Subred usa la Route Table principal sin IGW IP pública Auto-assign habilitado o EIP asignado Instancia sin IP pública Security Group Regla de salida 0.0.0.0/0 permitida Egress bloqueado por SG restr...
Leer más

Actualizar Contenido en CloudFront: Cómo Crear una Invalidación para Limpiar el Caché del Edge

Reemplazaste un archivo en S3, recargaste el navegador, y CloudFront sigue sirviendo la versión antigua. Es uno de esos momentos donde sabes exactamente qué pasó, pero necesitas la solución correcta ahora mismo — sin esperar que el TTL expire solo. Este artículo explica cómo funciona el caché de CloudFront y cómo crear una invalidación de CloudFront para forzar la purga inmediata del edge. TL;DR — Invalidación de CloudFront en 30 Segundos Situación Acción Archivo actualizado en S3, CloudFront sirve versión vieja Crear invalidación con la ruta del archivo Múltiples archivos actualizados Usar wildcard /* o listar rutas específicas Quieres evitar invalidaciones frecuentes Usar versionado de archivos en el nombre (cache busting) Herramienta Consola AWS, CLI ( aws cloudfront create-invalidation ), o SDK Cómo Funciona el Caché de CloudFront CloudFront opera como una red de puntos de presencia distribui...
Leer más

Aumentar el Timeout de Lambda: Configuración, Límites y Diagnóstico en Producción

Tu función Lambda se detiene a los 3 segundos, pero el proceso que ejecuta necesita 10. No es un bug en tu código — es el timeout por defecto de Lambda actuando exactamente como fue diseñado. El problema es que ese valor predeterminado de 3 segundos sorprende a casi todos la primera vez, especialmente cuando la función funciona perfectamente en local pero falla en producción con un error Task timed out after 3.00 seconds . TL;DR — Aumentar el Timeout de Lambda Aspecto Detalle Timeout por defecto 3 segundos Timeout máximo 15 minutos (900 segundos) Dónde configurarlo Consola AWS, CLI, CloudFormation, SAM, Terraform Error observable Task timed out after X.XX seconds Coste asociado Mayor timeout = mayor ventana de facturación potencial Alternativa para tareas largas AWS Step Functions o procesamiento asíncrono Cómo Funciona el Timeout en AWS Lambda Lambda ejecuta tu función dentro de un entor...
Leer más