Casi todo proyecto de nube empieza mal de la misma manera: alguien crea un proyecto en la consola, levanta una máquina para probar, la prueba se vuelve piloto y el piloto se vuelve producción. Seis meses después hay treinta proyectos sin estándar de nombres, permisos asignados a correos individuales, redes superpuestas y una factura que nadie sabe explicar. La landing zone es lo contrario de eso: la base de la nube diseñada antes que las aplicaciones, descrita en código y construida en un orden que evita retrabajo.

Este artículo es el complemento práctico de nuestro texto sobre Terraform con IA, que trata el método y las barreras de protección de la infraestructura como código. Aquí mostramos la secuencia real de construcción de una base en Google Cloud: qué va antes que qué, dónde la IA ayuda de verdad y qué decisiones de costo deben nacer junto con la primera línea de código.

Por qué «landing zone» y no «creamos un proyecto y vemos»

El proyecto suelto parece inofensivo porque no tiene costo de decisión. El problema aparece cuando tiene que convivir con otros. Una landing zone resuelve cuatro cosas de una vez, y las cuatro son caras de resolver a las apuradas.

• Jerarquía. En GCP, la organización, las carpetas y los proyectos no son cosmética: son el punto en el que las políticas y los permisos pasan a heredarse. Una organization policy que bloquea IP externa, aplicada en la carpeta de producción, vale para todo lo que nazca allí dentro, incluido el proyecto que alguien cree mañana sin avisar.
• IAM desde el día 1. El proyecto suelto casi siempre nace con un owner personal. Eso es deuda inmediata: cuando esa persona se va de la empresa, nadie sabe qué se rompe al quitarle el acceso.
• Red planificada. Los rangos de IP se eligen una sola vez. Dos subredes superpuestas impiden el peering y solo aparecen el día en que el entorno necesita hablar con el resto de la empresa.
• Facturación separada por entorno. Producción, homologación y desarrollo en proyectos distintos es lo que vuelve legible el costo. Sin eso, cualquier conversación de FinOps empieza con tres semanas de arqueología.

Además, con la base lista, levantar un entorno nuevo deja de ser un proyecto y pasa a ser una ejecución de código.

El orden de construcción que evita retrabajo

La secuencia siguiente no es estética: cada capa consume la salida de la anterior, e invertir el orden significa rehacer.

1. Organización y carpetas. Primero el árbol: carpetas por entorno (producción, no producción) y una común para red, logs y herramientas. Aquí entran las organization policies que valen para siempre: regiones permitidas, prohibición de clave estática, bloqueo de acceso público en storage.
2. Proyectos por entorno. Un proyecto por entorno y por dominio de responsabilidad, con nombre estandarizado y facturación vinculada. El proyecto es la unidad de cuota, aislamiento y costo de GCP: usar pocos «para simplificar» es el error más común y el más caro.
3. IAM con grupos, nunca usuario directo. Los permisos van a grupos del directorio corporativo, y las personas entran y salen de los grupos: un rol en un correo individual no es auditable en la práctica. La misma regla vale para las cuentas de servicio: alcance mínimo, una por aplicación, con impersonation en lugar de clave.
4. VPC y subredes. Aquí entra la VPC compartida: una red en un proyecto host, consumida por los proyectos de servicio, lo que evita que cada aplicación invente la suya. Planifique los rangos con holgura y guarde el plan de direccionamiento en el repositorio, no en una planilla.
5. Conectividad. Salida por Cloud NAT, para que la carga no necesite IP pública; firewall por cuenta de servicio o etiqueta, no por rango suelto; y Private Service Connect cuando haya base de datos gestionada: una base con IP pública es el hallazgo recurrente de cualquier evaluación de seguridad.
6. Workloads. Recién ahora entran Cloud Run o GKE. La elección es de operación, no de moda: Cloud Run cobra por solicitud y desaparece sin tráfico; GKE da control fino y cobra el clúster incluso ocioso.
7. Observabilidad. Por último, lo que cierra el ciclo: log sinks centralizados en un proyecto propio, retención definida y alertas con destino real, no un buzón de correo que nadie lee.

Lo que la IA acelera aquí

La landing zone es trabajo repetitivo y estructurado, exactamente el terreno en el que los asistentes de IA rinden. Cuatro usos se pagan ya en el primer entorno.

• Módulos reutilizables. Describir «proyecto estándar con APIs habilitadas, cuenta de servicio, etiquetas obligatorias y sink de log» y recibir el módulo con variables y outputs saca el trabajo mecánico del camino. La ganancia real es la consistencia: el quinto proyecto sale igual que el primero.
• Revisión del plan buscando destrucción. En una base, el peligro no es crear un recurso de más: es que el plan proponga recrear una subred porque alguien tocó un atributo inmutable. Un resumen de lo que será destruido o forzado a recrearse convierte cientos de líneas de diff en una lista corta para decidir.
• Documentación de la landing zone. Tabla de proyectos, plan de direccionamiento y matriz de grupos y roles, generados a partir del código real y, por eso, todavía ciertos al mes siguiente.
• Convertir el diseño en código. Del diagrama al primer esqueleto de módulos es donde la IA más ahorra tiempo, siempre que el diseño ya traiga las decisiones de red y jerarquía tomadas por personas.

State y seguridad de la propia base

El código que crea toda la nube es el activo más sensible del entorno. Tres reglas no se negocian.

Primero, el state vive en un bucket dedicado, en un proyecto propio de herramientas, con versionado activado y bloqueo de concurrencia. El versionado permite volver de un estado corrupto; el lock evita que dos apply simultáneos destruyan el archivo. El acceso es restringido: quien lee el state lee el inventario completo del entorno.

Segundo, una cuenta de servicio por pipeline, con el menor privilegio que aún permita hacer el trabajo: la identidad que aplica producción no es la que aplica desarrollo. Tercero: ninguna clave estática en el repositorio. La autenticación debe ser por federación de identidad, con credencial de vida corta emitida en el momento. Una clave de cuenta de servicio en un archivo JSON es la filtración que más aparece en auditoría, y la organization policy que prohíbe crearlas debe estar activa desde el primer día.

FinOps desde la base

El costo no es asunto del sexto mes. Dos cosas nacen con la landing zone. La primera son las etiquetas obligatorias —entorno, centro de costo, aplicación, responsable—, aplicadas por módulo y bloqueadas en el pipeline cuando faltan: un recurso sin etiqueta es un recurso que nadie explica en la factura. La segunda es el presupuesto con alerta por proyecto, con umbrales en porcentajes y un destinatario que le haga seguimiento.

Y hay una lección de campo que vale más que una regla genérica. En una evaluación de FinOps en Google Cloud para una aseguradora brasileña, encontramos CUDs (committed use discounts, descuentos por compromiso de uso de uno a tres años) contratados para base de datos gestionada con utilización prácticamente nula, y compromisos flexibles de cómputo consumidos en menos de la mitad. El descuento existía en el papel; el gasto seguía allí, todos los meses, sin contrapartida.

Checklist de la landing zone

• Jerarquía de organización y carpetas en código, con organization policies heredadas.
• Proyectos separados por entorno, con nombre estandarizado por el módulo y facturación vinculada.
• IAM solo por grupos; ningún rol en correo individual; cuentas de servicio con alcance mínimo.
• Plan de direccionamiento IP documentado, sin superposición con la red local.
• VPC compartida con proyecto host y firewall por identidad, no por rango.
• Cloud NAT en la salida; acceso privado a los servicios gestionados; ninguna base con IP pública.
• Bucket de state con versionado, lock y acceso restringido.
• Pipeline con identidad federada, sin clave estática; plan en el pull request y apply solo tras la aprobación.
• Etiquetas obligatorias validadas en el pipeline y presupuesto con alerta por proyecto.
• Log sinks centralizados, retención definida y alertas con destinatario real.
• Verificación periódica de drift, con la corrección hecha en el código.

Para profundizar antes del primer módulo, dos materiales ayudan. En la Inove Academy, la guía rápida de migración a la nube orienta sobre qué va por lift-and-shift y qué merece rediseño, una decisión que cambia el diseño de la landing zone. Y la calculadora FinOps da el orden de magnitud del desperdicio antes de cualquier compromiso: exactamente la medida que falta cuando un CUD se compra por impulso.

Al final, la landing zone no es un entregable bonito de arquitectura. Es la diferencia entre una nube que crece por adición y una que crece por remiendo. La primera absorbe la próxima aplicación en horas; la segunda cobra, con cada nueva carga, el precio de las decisiones que nadie quiso tomar al principio.