Cerramos el Capítulo 30 juntando los dos grandes hilos del libro: por un lado, Terraform (la infraestructura como código, que dominamos en las Partes II-V) y, por otro, la estructura multi-cuenta que acabamos de ver. La pregunta natural es: si gestionamos toda nuestra infraestructura con Terraform, y ahora tenemos muchas cuentas, ¿cómo aplicamos Terraform de forma ordenada a toda esa estructura? Aquí es donde todo lo aprendido converge en una práctica de nivel experto.

Hasta ahora, implícitamente, hemos usado Terraform sobre una cuenta. Pero una empresa con la estructura del subcapítulo 30.1 tiene decenas de cuentas (por entorno, equipo, proyecto). Gestionar la infraestructura de todas ellas con Terraform, de forma coherente y sin caos, requiere aplicar bien las técnicas que ya conoces. La buena noticia: ya tienes todas las piezas, solo hay que combinarlas a escala.

Lo bonito de este subcapítulo es que no hay nada nuevo que aprender: es la culminación de técnicas que ya dominas. Repasémoslas en el contexto multi-cuenta:

Recuerda los módulos (Capítulo 18): bloques reutilizables de infraestructura. En un entorno multi-cuenta son esenciales: defines tu infraestructura estándar (una red, una aplicación...) una vez como módulo, y la reutilizas en todas las cuentas que la necesiten. Esto garantiza consistencia (todas las cuentas usan la misma definición) y evita duplicar código.

Recuerda la importancia del estado (Capítulo 11) y los backends remotos (Capítulo 20). En multi-cuenta, cada cuenta (o cada combinación cuenta+entorno) debe tener su propio estado separado, igual que separábamos entornos (Capítulo 19). Así, gestionar una cuenta no afecta a las demás: el aislamiento de la infraestructura como código refleja el aislamiento de las cuentas.

Recuerda las técnicas para gestionar múltiples entornos (Capítulo 19): directorios por entorno, variables por entorno (.tfvars), y herramientas como Terragrunt (subcapítulo 19.3) para mantener el código DRY. Estas mismas técnicas se aplican ahora a múltiples cuentas: cada cuenta es, en cierto modo, otro «entorno» que configurar con las mismas variables-pattern y estructura ordenada.

Recuerda el CI/CD para Terraform (Capítulo 22): pipelines que aplican los cambios de forma controlada, con revisión y plan antes de apply. A escala multi-cuenta, los pipelines despliegan a cada cuenta de forma automatizada y segura, con los controles adecuados (especialmente estrictos para las cuentas de producción).

El mensaje central: gestionar Terraform en multi-cuenta no requiere magia nueva, sino aplicar con disciplina las buenas prácticas que ya conoces, a mayor escala. Módulos para reutilizar, estados separados para aislar, estructura de entornos para organizar, y CI/CD para desplegar con control.

Analogía: gestionar Terraform en multi-cuenta es como dirigir una cadena de restaurantes con recetas estandarizadas. No reinventas la cocina en cada local: tienes recetas únicas (módulos) que cada restaurante (cuenta) sigue igual, garantizando la misma calidad en todos. Cada restaurante lleva su propia caja y cocina (estado separado), así que un problema en uno no afecta a otro. Tienes un manual de operaciones común (estructura de entornos) y un proceso estándar de apertura de locales nuevos (CI/CD). El secreto no es una técnica nueva, sino aplicar las mismas buenas prácticas con disciplina en todos los locales.

Terraform y Control Tower (subcapítulo 30.2) trabajan juntos, en niveles distintos:

• Control Tower gobierna la estructura organizativa: crea las cuentas, aplica los guardrails, monta la landing zone (los «cimientos» y las «normas comunes»).
• Terraform despliega la infraestructura concreta dentro de cada cuenta: las redes, los servidores, las aplicaciones (lo que «construyes encima» de los cimientos).

Ambos se complementan: uno prepara el terreno multi-cuenta, el otro construye sobre él de forma reproducible.

Ejemplo del mundo real: una empresa con 30 cuentas gestiona toda su infraestructura con Terraform aplicando las prácticas que conoce. Tienen una biblioteca de módulos (red estándar, aplicación estándar, base de datos estándar) versionados (recuerda el subcapítulo 18.4), que todos los equipos reutilizan: así, la red de la cuenta de un equipo es idéntica en estructura a la de otro, sin duplicar código. Cada cuenta+entorno tiene su estado separado en backends remotos (Capítulo 20), de modo que desplegar en dev-equipoA jamás puede afectar a prod-equipoB. Usan Terragrunt (subcapítulo 19.3) para mantener todo DRY across cuentas, y pipelines de CI/CD (Capítulo 22) que aplican los cambios con revisión y plan previo, con aprobaciones extra para producción. El resultado: gestionan 30 cuentas con la misma consistencia, seguridad y control que tendrían con una, porque aplicaron las buenas prácticas con disciplina a escala. Eso es infraestructura como código de nivel experto.

• Gestionar Terraform sobre decenas de cuentas (multi-cuenta) requiere aplicar con disciplina las técnicas que ya conoces, no aprender magia nueva. Todas las piezas ya las tienes.
• Las piezas que encajan:
  • Módulos (Cap. 18): define la infraestructura una vez y reutilízala en todas las cuentas → consistencia sin duplicar código.
  • Estado separado por cuenta (Caps. 11, 20): cada cuenta con su propio estado → aislamiento (cambiar una no afecta a otra).
  • Gestión de entornos (Cap. 19): directorios, .tfvars, Terragrunt → organización ordenada de muchas cuentas.
  • CI/CD (Cap. 22): pipelines con revisión y plan → despliegues controlados a cada cuenta (estrictos en producción).
• Como una cadena de restaurantes con recetas estandarizadas: mismas recetas (módulos), cocina propia por local (estado separado), manual común (entornos), proceso de apertura estándar (CI/CD).
• Control Tower (gobierna las cuentas/landing zone) y Terraform (construye la infraestructura dentro de cada cuenta) se complementan en niveles distintos.

¡Has completado el Capítulo 30 y dominas la organización multi-cuenta y las landing zones! En el Capítulo 31, que cierra la Parte VII, veremos una disciplina muy actual que lleva todo esto un paso más allá: el Platform Engineering y las plataformas internas para desarrolladores.