Por Mid 
Con Terraform AWS DynamoDB defines tablas NoSQL administradas, índices secundarios globales y políticas de escalado bajo demanda o aprovisionado como infraestructura versionada. Es el complemento natural cuando ya modelas redes con Terraform AWS VPC o almacenamiento con otros recursos AWS: un solo terraform apply crea la tabla, los GSIs y las alarmas mínimas para coste y latencia. El enfoque IaC reduce variaciones entre entornos y deja constancia para auditorías y recuperación ante desastres.
- Qué obtienes: recurso
aws_dynamodb_table, ejemplo de GSI, alarmas sugeridas y variables por entorno. - Qué necesitas: provider AWS, permisos IAM sobre DynamoDB y backend remoto para el estado.
- Salida práctica: ARN y nombre de tabla listos para aplicaciones, Lambdas y pipelines CI.
Contenido
Terraform AWS DynamoDB: cuándo encaja en tu arquitectura AWS
Terraform AWS DynamoDB encaja cuando necesitas clave-valor y documentos con latencia predecible sin operar clusters propios. Se integra con IAM fino, cifrado KMS opcional y réplicas en otras regiones para lectura. Si ya orquestas contenedores con Terraform Helm Provider o redes con Terraform AWS VPC, reutiliza el mismo backend de estado y etiquetas corporativas.
La referencia del provider está en el recurso aws_dynamodb_table del Terraform Registry. La guía conceptual sigue en la introducción a DynamoDB en AWS y el modelo de permisos en la guía de acceso DynamoDB.
Los equipos que combinan API Gateway y Lambda suelen usar DynamoDB como almacén de sesiones o colas ligeras; en ese caso documenta límites de tamaño de ítem y expresiones de condición para evitar escrituras conflictivas. Si expones datos a clientes móviles, valida políticas de acceso finas y evita filtrar por atributos no indexados en producción.
La elección entre single-table design y múltiples tablas condiciona tus módulos Terraform: agrupa recursos relacionados en el mismo archivo o módulo para claridad, pero evita archivos gigantes difíciles de revisar en merge requests. Terraform AWS DynamoDB funciona mejor cuando el diseño de datos ya está consensuado antes de codificar.
Requisitos: provider, estado remoto y etiquetado
Configura el provider aws con región y credenciales (perfil SSO o rol asumido). Usa backend S3 con bloqueo DynamoDB para el estado de Terraform si varios equipos aplican cambios. Etiqueta tablas con Environment, Owner y CostCenter para Cost Explorer: sin etiquetas, optimizar Terraform AWS DynamoDB es adivinar.
El bloqueo de estado en DynamoDB es meta: la tabla de lock no debe confundirse con tablas de negocio; mantén nombres y permisos separados. Ejecuta terraform fmt y validate en pipeline antes de merge. Si comparas patrones multi-nube, revisa también Terraform GCP GKE para ver cómo el mismo equipo estructura módulos en otro proveedor.
Terraform AWS DynamoDB: tabla base con clave compuesta
Ejemplo mínimo con modo on-demand y cifrado por defecto:
resource "aws_dynamodb_table" "events" {
name = "app-events-${var.env}"
billing_mode = "PAY_PER_REQUEST"
hash_key = "pk"
range_key = "sk"
attribute {
name = "pk"
type = "S"
}
attribute {
name = "sk"
type = "S"
}
point_in_time_recovery {
enabled = true
}
server_side_encryption {
enabled = true
}
tags = {
Project = "blog-demo"
}
}
output "table_name" {
value = aws_dynamodb_table.events.name
}
Ajusta nombres de atributos a tu modelo de acceso. Evita crear atributos no usados en claves o GSIs: DynamoDB exige declararlos todos. Versiona cambios destructivos: borrar un GSI en uso puede tumbar consultas de producción.
Usa variables por entorno (dev, staging, prod) en el nombre de tabla o en prefijos controlados por Terraform workspaces. Limita longitud de nombres para no chocar con cuotas y mantén convenciones alineadas con otras tablas del equipo. Si necesitas condicionales por región, parametriza también endpoints y réplicas.
Antes del primer apply en producción, ejecuta planes en cuenta sandbox con datos sintéticos para validar que los permisos IAM del pipeline bastan y que no hay dependencias circulares con otros módulos (por ejemplo buckets KMS compartidos).
Documenta en el README del módulo qué variables son obligatorias y cuáles tienen valores por defecto seguro; reduce tickets de “plan vacío” o errores de tipo en CI. Incluye ejemplos de tfvars por entorno sin secretos reales.
Terraform AWS DynamoDB: GSI, LSI y streams
Los índices secundarios globales permiten patrones de consulta alternativos; cada uno incrementa coste de escritura y almacenamiento. Define global_secondary_index con proyecciones mínimas (KEYS_ONLY, INCLUDE o ALL) según necesidad. Habilita stream_enabled si integras Lambda o procesos de proyección; recuerda retención y fan-out.
Los LSI comparten throughput con la tabla base y solo se definen en creación: planifica bien porque no puedes añadirlos después. Si tu modelo evoluciona, suele ser más simple nuevos GSIs que rediseños forzados. Evalúa cardinalidad de partición en cada índice para evitar skew que degrade latencia.
Para replicación multi-región valora tablas globales en módulos separados; implica coordinación de versionado y conflictos de escritura. Terraform AWS DynamoDB modela recursos, pero el diseño de claves sigue siendo responsabilidad del equipo de datos.
Los streams habilitan integraciones con Terraform AWS Lambda cuando necesitas pipelines event-driven; define dead-letter queues y reintentos fuera del recurso de tabla para no perder eventos. Si exportas a almacenamiento objeto, alinea buckets gestionados con Terraform AWS S3 y políticas de ciclo de vida.
Terraform AWS DynamoDB: cifrado, IAM y cumplimiento
Activa cifrado en reposo con KMS gestionado o CMK según políticas; documenta rotación y quién puede usar la clave. Las políticas de tabla y de bucket (si exportas datos a S3 vía pipelines) deben alinearse: un rol con demasiados permisos en DynamoDB y S3 amplifica fugas. Si necesitas bloquear eliminaciones accidentales, valora deletion_protection en versiones recientes del provider.
Para entornos regulados, conserva evidencias de terraform plan aprobado y vínculos a tickets de cambio. Los accesos cross-account a tablas compartidas requieren políticas de recurso explícitas; prueba en staging antes de abrir lectura a otra cuenta workload. La combinación de Terraform AWS DynamoDB con roles OIDC en CI evita claves de larga duración en repositorios.
Habilita CloudTrail para llamadas de control plane y revisa periódicamente accesos inusuales a BatchWriteItem o Scan masivos que puedan indicar exfiltración. Restringe también permisos de etiquetado: etiquetas mal aplicadas rompen informes de coste y pueden ocultar recursos huérfanos.
En cuentas con SCPs de Organizations, valida que no bloqueen creación de tablas en regiones permitidas por arquitectura. Un error frecuente es desplegar módulos en eu-west-1 mientras la política solo permite eu-central-1: el fallo aparece tarde si no pruebas en cuenta sandbox.
Terraform AWS DynamoDB: errores frecuentes
Si apply falla por límite de tablas o throughput, revisa cuotas de cuenta y solicita aumento en AWS. Errores de validación de esquema suelen indicar atributos sin declarar o tipos inconsistentes entre clave y GSI. Tras importar recursos legacy, cuidado con drift: cambios manuales en consola pueden forzar sustituciones no deseadas.
Cuando habilitas streams y Lambdas disparadas, verifica permisos de la función y mapping de eventos fuera de Terraform si se crearon a mano. Mantén versionado de módulos y pin de provider para evitar sorpresas en CI.
Si el plan muestra sustitución completa de tabla por cambio de clave primaria, detente: suele requerir nueva tabla y migración de datos. Los cambios incrementales en GSIs son más seguros pero igualmente requieren prueba de carga. Documenta en el módulo qué operaciones están permitidas sin ventana extendida.
Los errores intermitentes de throttling en modo aprovisionado indican necesidad de auto scaling o reparto de carga; en on-demand revisa hot partitions. Monitoriza métricas ConsumedReadCapacityUnits y ConsumedWriteCapacityUnits para ajustar alarmas antes de que usuarios noten latencia.
Si observas latencias altas pese a capacidad suficiente, revisa patrones N+1 en la aplicación o consultas que disparan lecturas repetidas del mismo ítem; la infraestructura correcta no compensa lógica ineficiente en el cliente.
Modos de capacidad, alarmas y buenas prácticas
El modo aprovisionado exige ajuste de RCU/WCU y auto scaling; on-demand simplifica picos impredecibles con coste variable. Crea alarmas CloudWatch sobre consumo, throttling y tamaño de tabla. Revisa ítems grandes y hot partitions: Terraform no arregla un esquema mal diseñado.
Integra políticas IAM mínimas por aplicación; evita dynamodb:* en producción. Si combinas con Terraform AWS IAM, reutiliza patrones de roles por servicio. Documenta en el módulo cómo rotar KMS si usas claves CMK dedicadas.
Supervisa el tamaño medio de ítem: DynamoDB cobra almacenamiento y los ítems enormes penalizan lecturas/escrituras. Comprime datos de negocio o mueve blobs a S3 referenciados por clave. Para cargas mixtas lectura/escritura, diseña pruebas de carga que reproduzcan patrones reales antes de fijar modo aprovisionado.
En equipos que combinan datos relacionales y NoSQL, documenta qué dataset vive en RDS y qué dataset vive en DynamoDB para evitar duplicar fuentes de verdad. El patrón de Terraform AWS DynamoDB encaja con microservicios que necesitan baja latencia y esquema flexible, no como reemplazo one-to-one de SQL sin rediseño.
Programa revisiones trimestrales de coste real: tablas olvidadas en cuentas de desarrollo acumulan almacenamiento y GSIs innecesarios. Terraform facilita identificar recursos en código, pero los entornos creados manualmente pueden quedar fuera del repositorio; alinea inventario cloud con el estado IaC.
Terraform AWS DynamoDB: migraciones, import y convivencia con datos legacy
Cuando adoptas tablas existentes, usa terraform import sobre el identificador de tabla y revisa el plan: los índices creados en consola deben reflejarse literalmente en código o Terraform intentará modificarlos. Para datasets grandes, la migración de datos es independiente de IaC: usa AWS DMS, exportaciones a S3 o scripts controlados; Terraform no mueve filas.
Si mantienes entornos paralelos (blue/green), separa nombres de tabla por sufijo o cuenta y automatiza la promoción de DNS o configuración de aplicación solo tras validar integridad. Los backups point-in-time facilitan rollback de configuración, pero no sustituyen pruebas de aplicación tras cambios de esquema de acceso.
La gobernanza exige revisar quién aprueba destroy en producción: tablas con PITR habilitado permiten recuperación, pero el downtime y la reconfiguración de aplicaciones siguen costando. Añade revisión de código obligatoria cuando el plan muestre recreaciones por cambios de clave imposibles de aplicar in-place.
Para equipos multi-región, documenta dependencias entre réplicas y orden de creación: Terraform puede paralelizar recursos, pero las tablas globales requieren secuencia explícita con depends_on cuando el provider no infiere dependencias. Validar en staging con la misma topología reduce sorpresas en cutover.
Si integras pipelines de datos con Glue o Athena sobre exportaciones en S3, mantén la trazabilidad de quién generó cada snapshot, en qué ventana temporal y cómo se relaciona con la tabla DynamoDB origen. Los metadatos de gobernanza ayudan en auditorías y en incidentes de consistencia eventual cuando hay reprocesos o correcciones masivas.
FAQ sobre Terraform AWS DynamoDB
¿Puedo importar tablas existentes?
Sí, con terraform import; alinea atributos, índices y TTL antes del primer apply.
¿TTL se gestiona en Terraform?
Sí, mediante bloque ttl en el recurso de tabla y atributo de expiración acordado.
¿Qué pasa si cambio billing_mode?
Terraform muestra el plan detallado; valida ventana de cambio y posible impacto en throttling.
¿Cómo pruebo en local?
Usa DynamoDB Local o cuentas sandbox; no ejecutes pruebas destructivas contra producción.
¿Debo usar Scan en producción?
Evítalo salvo herramientas de mantenimiento puntuales; prefiere consultas por clave o índices diseñados para el patrón de acceso.
¿Qué hacer con tablas de prueba?
Etiquétalas y destrúyelas con Terraform al cerrar el proyecto para no acumular coste oculto.
Modelar Terraform AWS DynamoDB desde el inicio da trazabilidad y coherencia con el resto de tu IaC AWS. Itera diseño de claves con métricas reales y mantén el estado remoto protegido como cualquier recurso crítico. Para contexto de producto HashiCorp, revisa también HashiCorp y el flujo de trabajo recomendado en terraform-provider-aws. Si despliegas aplicaciones en contenedores locales antes de subir a AWS, puedes alinear variables con el enfoque de Docker Compose del blog para secretos y configuración.
Finalmente, incorpora en los equipos de revisión un checklist breve: ¿cambian claves o índices?, ¿hay impacto en coste mensual estimado?, ¿se probó el plan en sandbox?, ¿existen dependencias de aplicación no desplegadas todavía?, ¿se actualizó el diagrama de datos? Esas preguntas evitan merges apresurados que luego generan incidentes de fin de semana o deuda técnica silenciosa.