Diagrama de Azure Landing Zone: grupos de administración, suscripciones y red hub

La mayoría de los entornos de Azure empiezan igual. Alguien crea una suscripción para un piloto, luego otra para producción, y después cada equipo tiene la suya. Dos años más tarde, 40 suscripciones cuelgan del grupo raíz del tenant, tres ejecutan sus propias puertas de enlace VPN, una VM de base de datos tiene una IP pública y nadie sabe qué políticas se aplican dónde.

Una Azure landing zone es el plano de Microsoft para evitarlo. Esta entrada recorre cada parte con un diagrama: grupos de administración, landing zones de plataforma frente a las de carga de trabajo, barreras de política, hub-and-spoke frente a Virtual WAN, identidad y despliegue.

Qué es una Azure landing zone

El Cloud Adoption Framework (CAF) define una Azure landing zone como «una arquitectura probada y flexible para gobernar, proteger y escalar un entorno de Azure con varias suscripciones» (Microsoft Learn). Tiene dos partes:

• La landing zone de plataforma: la jerarquía de grupos de administración más los recursos compartidos, como la red hub, el registro y las herramientas de seguridad. Microsoft recomienda una por tenant de Microsoft Entra, gestionada por un equipo de plataforma.
• Las landing zones de carga de trabajo: una por carga de trabajo, propiedad de su equipo, con todos los entornos (desarrollo, pruebas, producción) como una o más suscripciones. El material antiguo las llama landing zones de aplicación.

La suscripción es el bloque de construcción: CAF la llama unidad de administración, facturación y escala. En términos de AWS, una suscripción equivale más o menos a una cuenta y un grupo de administración a una unidad organizativa; el diagrama de landing zone de AWS muestra ese lado.

La jerarquía de grupos de administración

Una asignación de política o de rol en un grupo de administración se aplica a todo lo que hay debajo, y los propietarios de suscripciones no pueden alterarla. Azure permite 10 000 grupos de administración por tenant, seis niveles bajo la raíz y un solo padre cada uno, según la documentación de grupos de administración.

La jerarquía de referencia, con notas de las asignaciones de política de ALZ por defecto:

Tres reglas de la guía de grupos de administración de CAF ahorran la mayoría de los rediseños:

1. Mantenla plana. Tres o cuatro niveles bastan; no añadas grupos de administración para regiones ni para desarrollo, pruebas y producción.
2. Asigna en la raíz intermedia, no en la raíz del tenant. Las suscripciones nuevas aterrizan por defecto bajo la raíz del tenant, y cualquier usuario puede crear grupos de administración hasta que exijas permiso. Cambia ambas cosas y haz de Sandbox el valor por defecto.
3. Da a los equipos de carga de trabajo roles en el ámbito de la suscripción. Los equipos de plataforma pueden tener roles en grupos de administración, controlados con acceso justo a tiempo.

Los nombres cambian: Security se unió a Platform en 2025, y la visión general más reciente de CAF usa «Workload landing zones» para Landing zones e «Internal» para Corp.

Landing zones de plataforma frente a las de carga de trabajo

En el subscription vending, una solicitud, a menudo una pull request, crea la suscripción bajo Corp u Online, asigna roles y un presupuesto y, para Corp, añade un spoke emparejado con el hub. Microsoft publica módulos de vending para Bicep y Terraform.

Barreras guiadas por política

Azure Policy convierte la jerarquía en cumplimiento: asigna una regla una vez en un grupo de administración y cada suscripción actual y futura de debajo la hereda.

Las reglas de región requieren cuidado: la política integrada Allowed locations omite los grupos de recursos y la ubicación global, así que combínala con Allowed locations for resource groups y empieza en modo DoNotEnforce para ver qué bloquearía:

az policy assignment create \
  --name allowed-locations \
  --scope /providers/Microsoft.Management/managementGroups/contoso \
  --policy e56962a6-4747-49cd-b67b-bf8b01975c4c \
  --params '{"listOfAllowedLocations": {"value": ["westeurope", "northeurope"]}}' \
  --enforcement-mode DoNotEnforce

El momento importa: una asignación nueva se aplica en unos cinco minutos, una suscripción movida a un grupo de administración se evalúa en unos 30 minutos y un análisis completo se ejecuta cada 24 horas. Las políticas DeployIfNotExists y Modify actúan sobre recursos nuevos y actualizados; los existentes necesitan una tarea de corrección.

Redes: hub-and-spoke o Virtual WAN

La suscripción de conectividad es dueña de la red compartida: Azure Firewall, puertas de enlace VPN y ExpressRoute, Bastion, zonas DNS privadas y el DNS Private Resolver. La guía de topología de red de CAF ofrece dos diseños:

El emparejamiento no es transitivo, así que en una red virtual hub cada spoke recibe una tabla de rutas que envía 0.0.0.0/0 a la IP privada del cortafuegos, el emparejamiento del hub permite el gateway transit y el emparejamiento del spoke usa la puerta de enlace remota; la entrada sobre la topología de red hub-and-spoke explica el enrutamiento. Azure Firewall Basic gestiona hasta 250 Mbps, Standard 30 Gbps y Premium 100 Gbps. Para Virtual WAN, elige el tipo Standard; Basic solo admite VPN de sitio a sitio.

El DNS es donde los equipos se equivocan más a menudo. Las zonas DNS privadas como privatelink.blob.core.windows.net viven en la suscripción de conectividad, vinculadas al hub, donde el DNS Private Resolver reenvía a Azure DNS en 168.63.129.16; los servidores DNS locales le reenvían zonas como blob.core.windows.net. Una política DeployIfNotExists en Corp escribe el registro de cada punto de conexión privado en la zona central, así que los equipos de carga de trabajo no necesitan permisos sobre ella.

Identidad

El tenant de Microsoft Entra es el límite de identidad. Las reglas prácticas de CAF:

• Da a los equipos de carga de trabajo roles en sus propias suscripciones durante el vending, nunca en grupos de administración.
• Deja que los ingenieros de plataforma activen roles como Owner mediante Privileged Identity Management (PIM), con aprobación y límite de tiempo.
• Aplica acceso condicional a todos los que administran Azure y mantén cuentas de acceso de emergencia supervisadas.
• Usa la suscripción de identidad para controladores de dominio o Microsoft Entra Domain Services si las cargas de trabajo aún los necesitan.

Desplegarla

En el momento de escribir esto (noviembre de 2026), Microsoft recomienda el Azure Landing Zones IaC Accelerator: Bicep o Terraform basados en Azure Verified Modules (AVM). Su módulo de PowerShell prepara un repositorio de GitHub o Azure DevOps, pipelines con aprobaciones e identidades administradas con credenciales federadas. Terraform usa módulos separados para la jerarquía y la política (avm-ptn-alz), los recursos de administración y cada diseño de red; Bicep usa deployment stacks, que pueden eliminar los recursos que quites de las plantillas.

Las opciones antiguas se retiran: el módulo de Terraform caf-enterprise-scale está obsoleto, y el ALZ-Bicep clásico salió del acelerador el 16 de febrero de 2026, con su repositorio por archivar el 16 de febrero de 2027. Queda un acelerador de portal, pero sin código es difícil de actualizar.

Presupuéstalo. La página de escenarios del acelerador estima la infraestructura fija en unos 5 640 USD al mes para un hub-and-spoke de una sola región con Azure Firewall, y 690 USD para la variante de pequeña empresa, que entre otras cosas desactiva el plan DDoS Network Protection (precios públicos de westus de abril de 2026, sin tráfico ni registros). También necesitas cuatro suscripciones de plataforma, o dos en la configuración de pequeña empresa.

El diagrama de Azure landing zone

Cómo leerlo:

• El árbol de la izquierda es la jerarquía; las flechas van del padre al hijo, la dirección de la herencia.
• El nodo de política cuelga de la raíz intermedia Contoso, no del grupo raíz del tenant, así que llega a toda la landing zone y a nada más.
• Los colores muestran la propiedad: azul para plataforma, verde para cargas de trabajo, ámbar para Sandbox, gris para la raíz y las suscripciones retiradas.
• Las aristas discontinuas muestran la ubicación: el hub vive en la suscripción de conectividad, y ambos spokes se provisionan en Corp.
• Las aristas continuas llevan tráfico: emparejamiento con el hub y enlace de la puerta de enlace con el entorno local; cada spoke enruta 0.0.0.0/0 al cortafuegos en 10.0.0.4.
• El bloque Markdown enumera los límites clave.

Dibujar con claridad diagramas de Azure landing zone

• Dibuja la gobernanza y la red como dos vistas, enlazadas solo donde vive una suscripción.
• Une cada política donde se asigna, para que los lectores vean qué cargas de trabajo restringe.
• Muestra una o dos suscripciones de ejemplo por grupo, no un inventario.
• Escribe los rangos de direcciones en el hub y en cada spoke; los solapamientos son lo primero que revisan los revisores.
• Evita los errores clásicos: emparejamiento dibujado como transitivo, cargas de trabajo bajo la raíz del tenant, y regiones o entornos como grupos de administración.

Consulta los diagramas de arquitectura cloud para nodos cloud tipados, y la entrada sobre el diagrama de arquitectura de Terraform para entornos gestionados con Terraform.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade ocho nodos Recurso en la nube del pack Nube: Tenant root group, Contoso, Platform, Landing zones, Corp, Online, Sandbox y Decommissioned. Pon cada rol en la línea del tipo de recurso y colócalos como un árbol con sangría.
3. Conecta padres con hijos mediante aristas ortogonales y colorea las ramas: azul para Platform, verde para Landing zones, ámbar para Sandbox.
4. Añade un nodo Política del pack Seguridad llamado Azure Policy guardrails y conéctalo a Contoso.
5. Añade un nodo VPC del pack Red para el hub, con un Enrutador para la puerta de enlace y un Cortafuegos dentro, y dos nodos VPC para los spokes, cada uno con una línea Texto del pack Básico para su ruta.
6. Dibuja aristas discontinuas de Platform al hub y de Corp a los spokes, aristas de emparejamiento al hub y una arista de la puerta de enlace a una etiqueta Texto del entorno local.
7. Añade un bloque Markdown del pack Básico con los límites.

Si tu landing zone está en Terraform, la herramienta Terraform to diagram convierte los archivos en un primer borrador.

El ejemplo usa 15 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Qué es una Azure landing zone? Un entorno de Azure con varias suscripciones construido según las recomendaciones del Cloud Adoption Framework antes de que lleguen las cargas de trabajo: grupos de administración, barreras de política, identidad, registro y una red compartida.

¿Qué grupos de administración usa una Azure landing zone? Una raíz intermedia bajo el grupo raíz del tenant, con Platform (Management, Connectivity, Identity, Security), Landing zones (Corp, Online, Local), Sandbox y Decommissioned por debajo.

¿Cuál es la diferencia entre las landing zones Corp y Online? Corp contiene cargas de trabajo que llegan a la red corporativa a través del hub, por lo que los valores por defecto deniegan allí los puntos de conexión PaaS públicos y las IP públicas en interfaces de red. Online contiene cargas de trabajo que necesitan acceso directo a internet o ninguna red virtual.

¿Debo usar hub-and-spoke o Virtual WAN? Una red virtual hub encaja con pocas regiones, menos de 30 túneles de sitio a sitio y control total del enrutamiento; Virtual WAN encaja con muchas regiones y sucursales, SD-WAN o tránsito de VPN a ExpressRoute.

¿Sigue siendo compatible el módulo de Terraform caf-enterprise-scale? No. Está obsoleto y no recibe actualizaciones. Usa los Azure Verified Modules para la landing zone de plataforma, normalmente mediante el acelerador IaC; Microsoft documenta una ruta de migración.

Empieza gratis — un puesto, sin tarjeta de crédito.