La prisa por "ya estar en la nube" tiene un efecto secundario predecible: alguien crea una cuenta, empieza a subir servidores, y meses después el entorno es un revoltijo de recursos sin orden, con accesos que nadie controla y una factura que nadie entiende. El problema no fue la nube; fue no haber armado los cimientos primero. A esos cimientos se les llama landing zone, y omitirlos es el error más caro —y más común— de una migración.
Qué es (y qué contiene) una landing zone
Una landing zone es la estructura base de tu entorno en la nube, montada antes de subir cargas productivas. No es un producto, es un conjunto de decisiones bien tomadas de una vez. Las piezas que la componen:
- Estructura de cuentas/suscripciones: cómo separas producción, pruebas y desarrollo, y por proyecto o unidad —en AWS con Organizations y unidades organizativas; en Azure con grupos de administración y suscripciones—. Separar bien es lo que evita que un experimento tumbe producción o mezcle costos.
- Identidad y accesos: inicio de sesión centralizado (integrado con tu directorio corporativo), roles con mínimo privilegio, y nada de credenciales sueltas circulando.
- Red: el diseño de la topología —típicamente un modelo hub-and-spoke: una red central para servicios compartidos y conectividad, y redes satélite por carga—, con su segmentación desde el día uno.
- Guardarraíles (políticas): reglas automáticas que impiden lo que no debe pasar —por ejemplo, crear recursos en regiones no autorizadas o sin cifrado—. Prevención, no vigilancia posterior.
- Registro y monitoreo: logs centralizados desde el inicio, para poder auditar e investigar.
- Gobierno de costos: etiquetado obligatorio, presupuestos y alertas —la base del gobierno de costos que evita la factura sorpresa—.
Por qué se arma ANTES de migrar
La razón es puramente económica: rehacer la cimentación con la casa ya construida encima es carísimo y arriesgado. Imagina descubrir a los seis meses que necesitas separar producción de pruebas, o imponer cifrado, o reorganizar la red —con decenas de cargas ya corriendo—. Cada corrección es un proyecto con riesgo de romper algo en producción. Hacerlo antes, sobre lienzo en blanco, cuesta una fracción. Sin landing zone, además, cada equipo crea recursos a su manera y el desorden crece exponencialmente, obligando después a un doloroso ejercicio de FinOps solo para entender qué hay.
No es solo para gigantes: la versión PyME
Un error frecuente es pensar que esto es para grandes corporativos. La escala cambia, el principio no. Una PyME no necesita docenas de cuentas ni una red hub-and-spoke elaborada, pero sí un mínimo ordenado: separar al menos producción de lo demás, identidad centralizada con MFA, una red pensada (no la default), cifrado por política, y etiquetado con alertas de presupuesto. Es una tarde de diseño que ahorra meses de desorden. El caos se acumula igual de rápido en entornos pequeños; simplemente tarda un poco más en doler.
Dónde encaja en la decisión mayor
La landing zone es la base física; encima van las decisiones de arquitectura. Revisar el entorno contra los cinco pilares de Well-Architected asume que existe una base ordenada sobre la cual evaluarlos. Y la estrategia de migración —lift-and-shift o replatforming— se ejecuta mucho mejor sobre una landing zone que sobre un terreno sin urbanizar. Es, literalmente, el paso cero.
La pregunta que conviene hacerse
Antes de subir la primera carga, la pregunta no es "¿qué migro primero?", sino ¿tengo lista la base de cuentas, identidad, red, guardarraíles, logs y costos para que esto no se vuelva un revoltijo imposible de ordenar después? Armar esa landing zone —proporcional a tu tamaño— es el primer entregable de cómo operamos infraestructura en la nube.