Casi todas las historias de terror en la nube empiezan igual: una cuenta única donde convive todo (producción, pruebas, experimentos de alguien que ya no está en la empresa), permisos de administrador repartidos con alegría y una factura que nadie sabe desglosar. Cuando el proyecto crece, ese caos se vuelve carísimo de arreglar. La solución tiene nombre desde hace años: landing zone. Hoy os cuento qué es y por qué merece la pena montarla antes de necesitarla.
Qué es una landing zone
Una landing zone es el andamiaje base de tu organización en la nube: la estructura de cuentas o suscripciones, la red, las identidades, las políticas de seguridad y la facturación, montadas de forma estandarizada antes de desplegar la primera aplicación. Es la diferencia entre construir sobre un solar urbanizado, con calles y alcantarillado, o plantar tu casa en mitad del campo e ir improvisando las tuberías.
Los pilares que no pueden faltar
- Multi-cuenta desde el principio: separar producción, preproducción, desarrollo y cargas compartidas en cuentas o suscripciones distintas. El aislamiento por cuenta es la barrera de seguridad y de radio de explosión más barata que existe.
- Identidad centralizada: un único punto de entrada con SSO federado contra tu proveedor de identidad, roles bien definidos y nada de usuarios locales con claves eternas repartidas por cada cuenta.
- Red planificada: rangos de IP que no se pisen entre entornos, conectividad centralizada (hub-and-spoke o similar) y decidido desde el día uno qué sale a internet y por dónde.
- Guardarraíles, no puertas cerradas: políticas preventivas (SCPs en AWS, Azure Policy, organization policies en GCP) que impidan lo peligroso — borrar el logging, crear recursos en regiones no aprobadas — sin bloquear la autonomía de los equipos.
- Logging y auditoría centralizados: todos los logs de actividad de todas las cuentas van a un sitio inmutable desde el primer día. Cuando haya un incidente lo agradecerás.
- Etiquetado y facturación: una convención de tags obligatoria (proyecto, entorno, propietario) para que la factura se pueda trocear. FinOps empieza aquí, no en el panel de costes.
Cómo montarla sin reinventar la rueda
Los tres grandes proveedores ofrecen soluciones de referencia: AWS tiene Control Tower y sus Organizations, Azure propone las landing zones de su Cloud Adoption Framework y Google estructura todo alrededor de carpetas y proyectos con sus blueprints. Son puntos de partida estupendos, pero mi consejo de trinchera es el mismo en los tres casos: define la landing zone como código (Terraform u OpenTofu son los reyes aquí) y trátala como un producto interno, con su repositorio, sus revisiones y su ciclo de vida. Una landing zone montada a clics es una landing zone que nadie sabrá reproducir.
¿Y si ya tienes el caos montado? No pasa nada: es el caso más habitual. Se empieza creando la estructura buena en paralelo, se mueven primero las cargas nuevas y se migra lo existente poco a poco, empezando por lo que menos duele. Es un proyecto de meses, no de días, pero cada carga que cruza deja de generar riesgo.
Conclusión
La landing zone es de esas inversiones invisibles: cuando está bien hecha nadie la nota, y cuando falta se nota cada semana. Si estás empezando en la nube, dedicarle unos días ahora te ahorrará meses de refactorización. Y si llevas años, nunca es tarde para ordenar la casa.
¿Tu organización tiene landing zone o vivís en la cuenta única del principio de los tiempos? Cuéntame tu experiencia en los comentarios 😊