Landing zone con AWS Control Tower: la fundación multi-cuenta que evita reconstruir todo en 2 años
Contexto
Cuando una empresa establecida — con operación on-premises, identidad corporativa en Azure Entra ID y equipos que ya funcionan — arranca un proyecto serio en AWS, la primera decisión no es qué base de datos usar. Es cómo se organizan las cuentas. Y casi todos la toman por omisión: una cuenta, todo adentro, “luego lo ordenamos”.
Este paper documenta el patrón contrario, aplicado en un engagement real de fundación enterprise: landing zone con AWS Control Tower — la estructura multi-cuenta, el gobierno y la red centralizada montados antes del primer workload. Una landing zone es exactamente eso: la zona de aterrizaje preparada para que todo lo que llegue después (aplicaciones, equipos, ambientes) caiga en un lugar gobernado.
Problema
La cuenta única funciona hasta que deja de funcionar, y cuando deja de funcionar ya es tarde:
- Radio de explosión: un error de permisos, una llave filtrada o un
terraform destroyequivocado alcanza TODO — producción, datos, backups. - Sin fronteras de gobierno: no puedes decirle “no” a un equipo por servicio, región o tipo de recurso sin estorbar a los demás. Los límites de servicio (quotas) se comparten y se agotan entre todos.
- Compliance imposible de demostrar: auditar quién tocó qué, cuando todo vive revuelto en una cuenta, es arqueología.
- Costos sin dueño: sin separación por cuenta, atribuir el gasto por ambiente o por equipo es un deporte de estimaciones.
- Y la restricción enterprise típica: la identidad ya vive en Entra ID y la red ya existe on-premises — AWS tiene que integrarse a eso, no al revés.
Arquitectura
Diagrama generado desde código (diagramas/generate_control_tower.py) con la librería diagrams + Graphviz.
Las piezas y su porqué:
- AWS Organizations + Control Tower en la cuenta Management: Organizations crea la jerarquía (OUs = unidades organizacionales, carpetas de cuentas); Control Tower monta encima la landing zone — guardrails preconfigurados, registro centralizado y Account Factory: la fábrica que crea cuentas nuevas ya gobernadas, con red y baseline aplicados, en minutos y no en tickets.
- Seis cuentas, cada una con un trabajo: Management (solo gobierno — aquí no corre nada), Networking (toda la conectividad), Shared Services (CI/CD e IaC), y Dev / Staging / Prod (los workloads, cada ambiente aislado). Staging a su vez separa 3 VPCs: testing, training y pre-producción.
- SCPs (Service Control Policies — los “no” que ninguna cuenta puede saltarse, ni siquiera su administrador): restricción de regiones, etiquetado obligatorio, protección de datos y cifrado, prevención de borrados destructivos, y control de costos bloqueando tipos de instancia caros.
- Identidad federada: Entra ID → IAM Identity Center vía SAML/SCIM. Nadie tiene usuarios IAM; la gente entra con su identidad corporativa y permission sets por rol y cuenta. Altas y bajas pasan donde siempre: en el directorio corporativo.
- Red centralizada en una sola cuenta: Transit Gateway como hub de todo el tráfico; firewall + WAF de siguiente generación para inspección Este-Oeste (VPC a VPC), ingress y egress; Direct Connect con BGP hacia on-premises; y VPNs site-to-site para integraciones con terceros. Los workloads no manejan su propia conectividad — se conectan al hub.
- Terraform para todo, desde Shared Services: la fundación completa es código modular con despliegue cross-account. La landing zone no se “configura”: se versiona.
- Auditoría y resiliencia como baseline: CloudTrail organizacional + AWS Config en todas las cuentas desde el día cero; AWS Backup con políticas en 4 frecuencias (diaria, semanal, mensual, anual) sobre RDS, S3, EFS, EBS y EC2; observabilidad integrada a la plataforma de monitoreo corporativa.
Decisiones
- Control Tower vs armar Organizations a mano: Control Tower impone opiniones (estructura de OUs, guardrails, cuentas de log/auditoría) a cambio de semanas de trabajo y de un estándar que AWS mantiene. Trade-off real: menos flexibilidad fina en la cuenta Management. Para una fundación nueva, se toma Control Tower y se personaliza con SCPs propias; armar todo a mano solo se justifica con requisitos que Control Tower no soporta.
- La home region se decide primero y con calma: Control Tower se ancla a una región “casa” y a las regiones adicionales gobernadas. Cambiarla después es cirugía mayor. La decisión pesa latencia a on-premises, servicios disponibles y residencia de datos — y se toma ANTES del setup, no durante.
- Federar identidad vs usuarios IAM: cero usuarios IAM. Trade-off: dependencia del directorio corporativo para entrar (si Entra ID cae, el acceso de emergencia es el break-glass de la cuenta Management). A cambio: offboarding instantáneo y un solo lugar donde viven los humanos.
- Inspección centralizada vs seguridad por VPC: todo el tráfico entre VPCs, entrante y saliente pasa por el firewall del hub. Trade-off: la cuenta Networking se vuelve crítica (y su equipo, cuello de botella potencial) a cambio de UN punto donde se ve y se controla todo el tráfico — el argumento que gana en cualquier auditoría.
- Ambientes como cuentas, no como VPCs: Dev, Staging y Prod son cuentas distintas, no subredes de la misma. Trade-off: más fricción de setup inicial a cambio de aislamiento real — quotas propias, facturación propia, y un blast radius que termina en la frontera de la cuenta.
Resultados
| Métrica | Valor | Fuente |
|---|---|---|
| Cuentas | 6 especializadas (Management, Networking, Shared Services, Dev, Staging, Prod) | diseño de landing zone |
| Familias de SCPs | 5 (regiones, tagging, datos/cifrado, anti-borrado, costos) | políticas desplegadas |
| VPCs de workload | 5 (Dev 1, Staging 3, Prod 1), todas colgadas del Transit Gateway | arquitectura de red |
| Conectividad híbrida | Direct Connect (BGP) + hasta 5 VPNs site-to-site | cuenta Networking |
| Usuarios IAM creados | 0 — todo federado Entra ID → Identity Center | diseño de identidad |
| Provisión de cuentas nuevas | Account Factory: minutos, ya gobernadas | Control Tower |
| Infraestructura como código | 100% Terraform modular, despliegue cross-account | repos de IaC |
| Backup | 4 frecuencias con retención por tier (RDS, S3, EFS, EBS, EC2) | AWS Backup |
Lecciones
- La landing zone es el producto, no el trámite. Cada semana invertida en la fundación se recupera multiplicada: la alternativa documentada en la industria es la “gran reorganización de cuentas” a los 2 años, con downtime y migraciones.
- Las SCPs baratas son las que más pagan: bloquear regiones no usadas y tipos de instancia caros toma minutos y elimina categorías enteras de sustos — de seguridad y de factura.
- El orden importa: identidad y gobierno primero, red después, workloads al final. Cada capa asume que la anterior existe; invertir el orden es rehacer.
- Account Factory cambia la cultura: cuando crear una cuenta gobernada toma minutos, los equipos dejan de compartir cuentas “mientras tanto” — y ese “mientras tanto” era el origen de todos los males del punto uno.
- Lo honesto: una landing zone así es sobre-ingeniería para una startup de 3 personas con una sola app. El patrón aplica cuando hay múltiples equipos, ambientes con compliance, u operación híbrida — y entonces no es opcional, es la diferencia entre escalar y reconstruir.