El cliente llegó con un problema que parece técnico pero no lo es: "Queremos movernos a la nube, pero cada equipo está haciendo las cosas a su manera y en seis meses vamos a tener un desastre". Tenían razón. Y la solución no era más documentación ni más políticas. Era una Landing Zone. Lo que no sabían es que diseñar una Landing Zone es, ante todo, un ejercicio de entender cómo funciona su empresa.
En los últimos tres años hemos diseñado Landing Zones para clientes de sectores muy distintos: una fintech con requisitos de compliance estrictos, una empresa de logística con cientos de servicios en on-premise y una startup de SaaS que quería escalar de cero a enterprise sin reescribir su infraestructura a mitad de camino.
Cada proyecto fue diferente. Pero el proceso de diseño tiene una estructura que se repite. Esto es lo que hacemos y por qué.
Qué es una Landing Zone y qué no es
Una Landing Zone es el entorno cloud fundacional sobre el que se despliegan todos los workloads de una organización. No es una cuenta de AWS con algunas políticas. Es la suma de decisiones de gobierno, seguridad, red, identidad, costes y operación que definen cómo tu organización usa la nube.
Lo que no es: una Landing Zone no es un proyecto que se termina. Es una plataforma viva que evoluciona con la organización. El error más caro que hemos visto es tratar la Landing Zone como un proyecto de infraestructura con fecha de entrega y no como un producto interno con roadmap propio.
Fase 1: Discovery — las preguntas que importan antes del primer diagrama
El error más común al empezar un proyecto de Landing Zone es abrir el editor de Terraform antes de entender la organización. Hemos aprendido a resistir esa tentación. Las primeras dos semanas son de preguntas, no de código.
Las preguntas que hacemos en el discovery:
- ¿Cuántos equipos van a usar la Landing Zone y con qué nivel de autonomía? Un equipo de plataforma centralizado que gestiona todo es muy diferente a cincuenta equipos de producto que despliegan de forma autónoma.
- ¿Qué normativas de compliance aplican? GDPR, PCI-DSS, ENS, SOC 2, ISO 27001 — cada una tiene implicaciones diferentes en el diseño de cuentas, logging y controles de acceso.
- ¿Cuál es el modelo de facturación interno? Si los equipos necesitan ver su propio gasto cloud, la estructura de cuentas es diferente a si solo lo ve finanzas.
- ¿Hay conectividad híbrida con on-premise? VPN, Direct Connect o ExpressRoute cambian fundamentalmente el diseño de red.
- ¿Cuál es el apetito de la organización para el cambio disruptivo? Algunas organizaciones pueden migrar todo a la vez. Otras necesitan convivencia durante años.
Las respuestas a estas preguntas determinan el 80% de las decisiones de diseño. El 20% restante son decisiones técnicas que vienen después.
Fase 2: Diseño de la estructura de cuentas
La estructura de cuentas es la decisión más importante y la más difícil de cambiar después. En AWS, hablamos de la estructura de AWS Organizations. En GCP, de la Resource Hierarchy. En Azure, de los Management Groups.
El principio que aplicamos siempre: una cuenta por entorno y propósito, no una cuenta para todo. La razón no es técnica, es de gobierno: los blast radius se contienen a nivel de cuenta. Un error en producción no puede afectar a otros entornos si están en cuentas separadas.
Estructura de cuentas que usamos como punto de partida
Fase 3: Diseño de red — el esqueleto que no se puede cambiar después
Si la estructura de cuentas es la decisión más importante, el diseño de red es la más dolorosa de cambiar a posteriori. Hemos visto proyectos paralizados durante semanas por un rango de IPs mal planificado al inicio.
El plan de direccionamiento IP
Antes de crear la primera VPC, definimos el plan de direccionamiento IP completo. Todos los rangos de todas las cuentas, todos los entornos, con espacio para crecer. La regla que seguimos: planifica para diez veces más del tamaño actual. Los rangos CIDR no cuestan nada. Quedarse sin IPs en producción sí.
Conectividad entre VPCs
Para organizaciones pequeñas, VPC peering es suficiente. A partir de cierto tamaño, AWS Transit Gateway, GCP VPC Peering o Azure vWAN son la respuesta. La elección depende del número de VPCs, los patrones de tráfico y si necesitas conectividad con on-premise.
El principio que aplicamos: hub-and-spoke. Una VPC de tránsito central que conecta todos los spokes. Simple de entender, simple de auditar, simple de escalar.
Acceso desde internet y salida a internet
Los workloads de producción no tienen IP pública directa. Todo pasa por un Application Load Balancer o un API Gateway en una subred pública. Las subredes de las aplicaciones son privadas. El tráfico de salida a internet pasa por NAT Gateways centralizados, no uno por VPC.
Fase 4: Identidad y control de acceso
La identidad es el perímetro de seguridad real en la nube. Los firewalls de red son necesarios pero insuficientes. Si las credenciales están mal gestionadas, el resto de controles son irrelevantes.
Nuestra arquitectura de identidad estándar tiene tres componentes:
- SSO centralizado: AWS IAM Identity Center, Azure AD o Google Workspace como proveedor de identidad. Un login para acceder a todas las cuentas con el nivel de permisos correspondiente. Nada de usuarios IAM locales con contraseñas.
- Permission sets por rol: Readonly, Developer, DevOps, SecurityAuditor, Administrator. Cada rol con los permisos mínimos necesarios. Los permission sets se gestionan como código y se despliegan automáticamente en todas las cuentas.
- Sin credenciales de larga duración: ningún acceso programático con access keys permanentes. Todo mediante roles asumidos con sesiones temporales. Las pipelines de CI/CD usan OIDC para asumir roles sin credenciales estáticas.
Fase 5: Guardarraíles — la diferencia entre control y burocracia
Los guardarraíles son los controles que definen qué pueden y qué no pueden hacer los equipos dentro de la Landing Zone. El equilibrio correcto entre control y autonomía es el arte de una buena Landing Zone.
Clasificamos los guardarraíles en dos categorías:
- Preventivos: bloquean acciones antes de que ocurran. SCPs en AWS Organizations, Azure Policies, GCP Organization Policies. Ejemplo: ningún equipo puede crear recursos fuera de las regiones aprobadas. Ninguna cuenta puede desactivar CloudTrail.
- Detectivos: alertan cuando algo ocurre fuera de la política. AWS Config Rules, Azure Policy en modo audit, Security Hub. Ejemplo: alerta cuando se crea un Security Group con acceso 0.0.0.0/0 al puerto 22.
La regla que seguimos: los guardarraíles preventivos son para las cosas que nunca deben ocurrir. Los detectivos son para las cosas que probablemente no deben ocurrir pero que a veces tienen excepciones justificadas.
Fase 6: Todo como código desde el primer recurso
Nada de lo anterior tiene valor si no está codificado, versionado y desplegable de forma repetible. La Landing Zone es el primer proyecto donde la disciplina de IaC es no negociable.
Nuestra estructura de repositorios estándar:
lz-org: estructura de AWS Organizations, SCPs, delegaciones de servicio.lz-network: VPCs, subredes, Transit Gateway, routes, peerings.lz-security: CloudTrail, GuardDuty, Security Hub, Config Rules, KMS keys.lz-identity: IAM Identity Center, permission sets, assignments.lz-accounts: vending machine de cuentas — creación automatizada de nuevas cuentas con toda la configuración base aplicada.
Cada repositorio tiene su propio pipeline de CI/CD con plan automático en PR y apply manual aprobado. Los cambios a la Landing Zone siguen el mismo proceso que los cambios a cualquier aplicación crítica.
Lo que nadie documenta: las decisiones políticas
La parte técnica de una Landing Zone es la más fácil. La parte difícil son las conversaciones que hay que tener antes de escribir una línea de Terraform.
¿Quién tiene acceso de administrador a las cuentas de producción? ¿Puede un developer hacer deploy directamente o todo pasa por una pipeline? ¿Qué hace el equipo de seguridad cuando una alerta de GuardDuty se dispara a las 3 de la mañana? ¿Qué equipo es responsible de mantener la Landing Zone cuando nosotros no estemos?
Estas preguntas no tienen respuesta técnica. Tienen respuesta organizacional. Y si no se responden antes de desplegar, aparecen como incidentes después.
Cuánto tiempo lleva y qué se puede esperar
Una Landing Zone básica —estructura de cuentas, red, identidad y guardarraíles esenciales— puede estar lista en 4-6 semanas para una organización mediana. Una Landing Zone enterprise con compliance estricto, conectividad híbrida y múltiples regiones puede llevar 3-4 meses.
Lo que siempre comunicamos: la Landing Zone inicial es un 60% del trabajo. El 40% restante es la operación, la evolución y el soporte a los equipos que van llegando. El proyecto no termina cuando el primer workload está en producción.
¿Estás planificando una Landing Zone?
Llevamos tres años diseñando Landing Zones para clientes de todos los tamaños. Te contamos cómo lo haríamos en tu caso y qué decisiones son las más críticas en las primeras semanas.
Hablar con un arquitecto →