Terraform + AWS: De estados gigantes a deploys de 3 minutos

“Llevamos 3 meses sin tocar nuestra infraestructura AWS por miedo a romper algo”. ¿Te suena? La solución no es cambiar de herramienta, es cambiar de metodología.

La mentira que nos hemos creído

Todos empezamos igual: “Vamos a hacer Infrastructure as Code, será genial”. Y efectivamente, los primeros días son mágicos. Creas tu primera VPC, tus security groups, unas cuantas instancias… Todo funciona. Te sientes como un mago.

Después llega la realidad.

Seis meses después tienes estados gigantes, módulos acoplados hasta las cejas, y cada cambio es una ruleta rusa. ¿Te suena?

1. terraform plan → 20 minutos esperando
2. Plan de 400 líneas que nadie entiende
3. “¿Seguro que quieres aplicar esto?”
4. Tres horas de debugging porque algo falló en la línea 247

Pero hay un factor que pocos equipos consideran…

Lo que realmente funciona (y por qué nadie te lo cuenta)

Después de rescatar decenas de proyectos de Terraform, la fórmula es más simple de lo que crees:

Estados pequeños + módulos inteligentes + GitOps que no dé miedo.

Estados por capas (no por proyecto)

Olvídate de “un estado para gobernarlos a todos”. Divide así:

terraform/
├── network/     # VPC, subnets, NAT gateways
├── data/        # RDS, ElastiCache  
├── compute/     # EKS, ECS, ASGs
└── apps/        # ALBs, Route53

Cada capa evoluciona independientemente. El equipo de datos puede actualizar RDS sin tocar la red. Este puede ser tu Game changer.

El truco del remote state

La magia está en conectar capas sin acoplarlas:

data "terraform_remote_state" "network" {
  backend = "s3"
  config = {
    bucket = "company-terraform-states"
    key    = "network/terraform.tfstate"
  }
}

# Usar outputs de otra capa
subnet_id = data.terraform_remote_state.network.outputs.private_subnet_id

Módulos que no dan dolor de cabeza

Para cada tipo de workload, un módulo específico:

• secure-webapp/ – ALB + WAF + instancias
• microservice/ – EKS service + ingress + monitoring
• data-pipeline/ – Lambda + SQS + RDS con backups

Nada de módulos “universales” que requieren 47 parámetros.

El multi-cloud ya está aquí

Aquí es donde se pone interesante. Muchos equipos están adoptando estrategias híbridas: AWS para aplicaciones críticas, OpenStack para desarrollo y testing.

¿Por qué? Coste y control.

# Mismo módulo, diferente cloud
module "webapp" {
  source = "./modules/webapp"
  
  # En OpenStack para dev
  provider = openstack.dev
  instance_type = "m1.medium"
  
  # En AWS para prod  
  # provider = aws.prod
  # instance_type = "t3.medium"
}

El futuro no es “AWS o nada”. Es flexibilidad arquitectónica. El poder elegir la solución que quieras cuando tu quieras y adaptado a tu presupuesto.

OpenTofu cambia las reglas del juego

Con los cambios en Terraform, OpenTofu se está convirtiendo en la opción inteligente. Misma sintaxis, governance open source, zero vendor lock-in.

La ventaja es brutal: puedes migrar gradualmente sin cambiar ni una línea de código. Perfecto para equipos que quieren control sin dramas.

La pregunta que deberías hacerte

¿Tu último terraform apply te quitó años de vida?

Si la respuesta es sí, el problema no es técnico. Es metodológico.

¿Reconoces estos síntomas en tu equipo? La diferencia entre el éxito y el infierno está en aplicar las técnicas correctas desde el principio.

Si quieres profundizar en estas metodologías, nuestros cursos de Terraform/OpenTofu cubren desde fundamentos hasta GitOps avanzado con casos reales multi-cloud.