Una landing zone para empresas medianas, en Terraform o Bicep: las piezas que importan

Una landing zone es el terreno preparado en el que aterrizan tus cargas cloud: la estructura de cuentas y suscripciones, las barreras, la identidad, la red, los logs y el control de costes, todo listo antes de que llegue la primera aplicación. Las arquitecturas de referencia para grandes empresas parecen necesitar un equipo de plataforma de veinte personas. Una empresa mediana necesita las mismas ideas en tamaño más pequeño, escritas como código, para que un equipo de dos pueda operarlas. Esta es la versión que construyo.

Dominik Heinrich

8 de noviembre de 202611 min de lectura

1. Qué abarca una landing zone

El Cloud Adoption Framework de Microsoft divide la landing zone de Azure en ocho áreas de diseño: facturación y el tenant de Entra, identidad y acceso, organización de recursos, topología de red y conectividad, seguridad, gestión, gobernanza y automatización de la plataforma con DevOps. Esa lista es una buena checklist aunque construyas algo mucho más pequeño que la arquitectura de referencia.

El objetivo de todo es sencillo: que los equipos puedan crear una suscripción nueva para una aplicación y encontrarse ya la seguridad, la red, los logs y el control de costes, en lugar de que cada equipo invente los suyos. Para una empresa mediana, eso significa unos pocos grupos de administración y políticas, una red hub, logs y presupuestos centrales, todo aplicado por un pipeline.

2. Grupos de administración por propósito, no por departamento

Los grupos de administración permiten aplicar políticas y accesos a muchas suscripciones a la vez. Un árbol puede tener hasta seis niveles, sin contar la raíz ni las suscripciones, pero una empresa mediana rara vez necesita más de dos o tres. Yo uso: un grupo de empresa arriba y debajo Plataforma (identidad, gestión, conectividad), Landing zones (separadas en internas y expuestas a internet si sus reglas difieren), Sandbox para experimentos con tope de presupuesto y Decommissioned para las suscripciones que se van.

Evita copiar el organigrama. Los departamentos se reorganizan; la diferencia entre una aplicación interna y una expuesta a internet no cambia. Los grupos por propósito mantienen estables las políticas cuando la empresa cambia.

Consejo práctico

Una suscripción por aplicación y entorno es un buen punto de partida: es la frontera más limpia para acceso, red y costes, y hace la factura legible sin magia de etiquetas.

3. Barreras como políticas, en lo más alto

Azure Policy es donde una landing zone demuestra su valor. Asigna las reglas al grupo de administración de la empresa para que se apliquen a todo lo que cuelga de él: regiones permitidas, etiquetas obligatorias, nada de IP públicas donde no hacen falta, configuración de diagnóstico enviada al workspace central y mínimos de cifrado y TLS. Empieza las reglas nuevas en modo auditoría, corrige lo que encuentren y luego pásalas a denegar.

En un proyecto de automoción, Azure Policies y Blueprints imponían líneas base de seguridad y reglas de red en todos los equipos, y una aplicación regulada pasó a Azure Kubernetes Service sin aflojar ni un solo control. Los equipos no tenían que recordar las reglas: la plataforma rechazaba lo que las incumplía.

hcl

# Allowed regions for everything under the company management group
resource "azurerm_management_group_policy_assignment" "allowed_locations" {
  name                 = "allowed-locations"
  management_group_id  = azurerm_management_group.company.id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c" # built-in: Allowed locations

  parameters = jsonencode({
    listOfAllowedLocations = { value = ["switzerlandnorth", "westeurope"] }
  })
}

Landing zone para una empresa mediana en Azure: Terraform o Bicep en Git aplicados por un pipeline; bajo la raíz del tenant de Entra ID, un grupo de administración de la empresa con políticas de regiones, etiquetas y sin IP públicas; un grupo Plataforma con identidad (grupos, PIM), gestión (logs, Defender), conectividad (red hub, firewall), presupuestos con alertas por suscripción y etiquetas de owner, centro de coste y entorno; un grupo Landing zones con suscripciones Corp y Online y redes spoke emparejadas con el hub; y grupos Sandbox y Decommissioned. — La estructura de landing zone que uso para empresas medianas: plataforma, landing zones, sandbox y decommissioned, todo aplicado como código. Haz clic para verlo a tamaño completo.

4. Una sola identidad, sin permisos de administrador permanentes

Todo inicia sesión mediante Entra ID. Da los permisos a grupos, nunca a personas concretas, para gestionar altas y bajas en un solo sitio. Owner y otros roles altos no se asignan de forma permanente: con Privileged Identity Management, la gente los pide para unas horas, con un motivo, y queda registrado.

Las aplicaciones usan identidades administradas en lugar de secretos guardados siempre que el servicio lo permite, y el resto de secretos vive en Key Vault con acceso por identidad. Mantén dos cuentas de emergencia fuera del flujo normal, muy protegidas y con alerta en cada inicio de sesión, para que una configuración de identidad rota no te deje fuera de tu propia nube.

5. Red: un hub y un spoke por carga

Hub-and-spoke es lo adecuado por defecto para la mayoría de empresas medianas. El hub contiene las piezas compartidas: el firewall, la conexión con la oficina o el centro de datos (VPN o ExpressRoute) y el DNS. Cada carga tiene su propia red spoke, emparejada con el hub, y el tráfico entre spokes y hacia internet pasa por el firewall, donde lo ves y lo controlas.

Planifica los rangos de direcciones una vez, para años, y apúntalos; los rangos solapados son de los errores más caros de arreglar después. Usa private endpoints para bases de datos y almacenamiento, de modo que no se puedan alcanzar desde internet, y deja que una política deniegue los endpoints públicos donde no están previstos.

6. Logs, seguridad y un presupuesto en cada suscripción

La suscripción de gestión contiene el workspace central de Log Analytics, Defender for Cloud y las alertas. Una política se asegura de que cada recurso nuevo envíe allí sus diagnósticos, para que nadie tenga que acordarse. Las alertas van a personas que pueden actuar, no a un buzón compartido que nadie lee.

El control de costes forma parte de la landing zone, no es un añadido. Cada suscripción tiene un presupuesto con alertas sobre la previsión, y cada recurso las etiquetas owner, centro de coste y entorno, impuestas por política. En el proyecto de automoción, los controles de costes y una estrategia de etiquetas hicieron que cada euro tuviera responsable; eso convierte la factura cloud de una sorpresa en una conversación.

7. Todo como código, aplicado por un pipeline

Una landing zone montada a clics en el portal se desvía en semanas. Escríbela como código en Git y deja que un pipeline la aplique, con un plan que alguien revisa antes de cada cambio. No tienes que empezar de cero: Microsoft mantiene código listo para la landing zone de Azure, para Terraform y para Bicep (el módulo de Terraform forma parte de Azure Verified Modules), que implementa la estructura de referencia y permite activar y desactivar partes.

Para una empresa mediana suelo coger esos módulos, recortarlos a lo que hace falta ahora y guardar la configuración en un repositorio pequeño: grupos de administración, asignaciones de políticas, la red hub, presupuestos y asignaciones de roles. Los equipos de aplicación nuevos reciben entonces una suscripción mediante un pull request, con todo lo anterior ya listo.

8. La misma estructura en AWS y Google Cloud

En AWS las piezas se llaman distinto pero hacen lo mismo. Las cuentas hacen el papel de las suscripciones, las unidades organizativas el de los grupos de administración y las service control policies ponen barreras sobre todas ellas. Fíjate en cómo funcionan las SCP: nunca conceden permisos, definen el máximo que pueden tener los roles de esas cuentas. AWS Control Tower monta una landing zone con estas piezas, aplica controles (también llamados guardrails) y crea cuentas nuevas a partir de plantillas con Account Factory.

Google Cloud publica su propia guía de diseño de landing zones con carpetas, políticas a nivel de carpeta y una VPC compartida por entorno. Estés en la nube que estés, las cinco decisiones son las mismas: estructura por propósito, barreras en lo más alto, una identidad sin permisos de administrador permanentes, una red y unos logs centrales, y todo como código.

Conclusión
Una buena landing zone es pequeña, aburrida y está escrita como código: estructura por propósito, barreras como políticas arriba, una identidad, una red hub, logs centrales y un presupuesto en cada suscripción.

Proyectos reales relacionados

Una carga regulada se muda a Azure, todo en Terraform

Pruébalo tú mismo

Estimar la factura cloud

¿Lo quieres en tu empresa? Hablemos mail@dominikheinrich.ch

Fuentes y guías oficiales

Más artículos