Tercer y último curso de la serie de nubes. A esta altura el método es conocido: la arquitectura vive en el curso de AWS, las diferencias de GCP quedaron mapeadas, y este curso gasta su espacio en lo que Microsoft hace distinto — que empieza antes del primer recurso, con una inversión filosófica que explica medio catálogo de Azure.

Concepto	En AWS	En GCP	En Azure
Raíz de todo	Organización	Organización	Tenant de Entra ID (el directorio)
Unidad de aislamiento	Cuenta	Proyecto	Suscripción
Unidad de ciclo de vida	— (tags)	— (el proyecto)	Resource group
Agrupador jerárquico	OUs	Carpetas	Management groups
Política central	SCP	Organization Policy	Azure Policy
Landing zone	Control Tower	Jerarquía + blueprints	CAF landing zones (documentadas)

La tesis del módulo

En AWS y GCP, la identidad es un servicio dentro de la nube; en Azure, la nube es un servicio dentro del directorio: todo cuelga del tenant de Entra ID — el mismo directorio donde viven los usuarios, grupos y aplicaciones de la organización. Esa inversión explica el sabor de Azure entero: la integración con el mundo corporativo Microsoft es nativa y profunda, y toda decisión de arquitectura empieza (y a veces tropieza) en el directorio. Además, Azure parte el aislamiento en dos niveles — suscripción para límites y facturación, resource group para ciclo de vida — donde las otras nubes usaban uno.

El tenant: la raíz que no es de la nube

El tenant es tu instancia de Microsoft Entra ID (el directorio de identidades, ex Azure Active Directory) — y existe antes que cualquier recurso de Azure: es el mismo directorio de Microsoft 365, donde viven los empleados, sus grupos y sus permisos corporativos. Azure se “cuelga” de él. Para una plataforma de agentes, dos consecuencias inmediatas:

La identidad de todo — humanos, servicios y agentes — vive en un solo plano. El aprobador humano del módulo 11 y la identidad del agente que pide aprobación son entradas del mismo directorio. Integrar con el mundo corporativo (¿quién es el jefe de quién? ¿qué grupo aprueba qué?) es consulta, no proyecto.
El tenant es la frontera de verdad. Suscripciones y recursos se administran, mueven y reorganizan; el tenant es el universo. Multi-tenant de verdad (organizaciones separadas) es un escenario avanzado y raro; para este curso, un tenant, y todo adentro.

Suscripciones y resource groups: el aislamiento en dos niveles

Suscripción (subscription): el contenedor de facturación, cuotas y límites — el nivel “cuenta de AWS”: dev, prod y sandbox como suscripciones separadas es el patrón base, con el radio de explosión y las cuotas partidas por diseño.
Resource group (RG): el nivel que AWS y GCP no tienen como ciudadano de primera clase — un agrupador de recursos con ciclo de vida común: los recursos del agente de triaje (su cómputo, su cola, su base) viven en un RG, se despliegan juntos, se les aplica permisos juntos y — la gracia — se borran juntos. El RG-por-agente es el equivalente funcional del proyecto-por-agente de GCP, un nivel más abajo: no aísla cuotas ni facturación (eso es la suscripción), pero sí organiza permisos, despliegue y limpieza.
Management groups: la jerarquía sobre las suscripciones — el lugar donde Azure Policy (el techo duro: “nada de IPs públicas”, “solo estas regiones”, “todo recurso lleva estos tags”) se declara una vez y se hereda hacia abajo, como las carpetas de GCP.

        LA JERARQUÍA DE AZURE

  tenant de Entra ID (el directorio corporativo)
        │
        ▼
  management groups (heredan Azure Policy)
        │
        ▼
  ┌──────────────────────────────────────┐
  │ suscripciones: prod · dev · sandbox  │
  │ (facturación, cuotas, límites)       │
  └──────────────────┬───────────────────┘
                     ▼
  resource groups: rg-agente-triaje,
  rg-agente-cotizador, rg-plataforma
  (ciclo de vida: nacen y mueren juntos)

La landing zone con manual: el Cloud Adoption Framework

Donde AWS da Control Tower y GCP da la jerarquía a armar, Microsoft da documentación prescriptiva: el Cloud Adoption Framework (CAF) y sus landing zones de referencia — la estructura de management groups, suscripciones, redes y políticas recomendada, con variantes por escala e incluso arquitecturas de referencia específicas para cargas de IA. Es el rasgo cultural de Azure que conviene conocer: para casi toda decisión de este curso existe un documento oficial con opinión. Bendición (no partes de cero) y riesgo (adoptar la landing zone enterprise completa para tres agentes es el anti-patrón de plataforma máxima con sello corporativo — la tabla de escalas del módulo 12 sigue mandando).

Las regiones funcionan como en las otras dos nubes — mismos tres criterios (datos, catálogo, latencia), misma advertencia de que el catálogo de IA favorece regiones grandes. Para Chile, dos de las tres nubes ya tienen región local: GCP (Santiago) y Azure — la región Chile Central (Santiago, tres zonas de disponibilidad) se inauguró en junio de 2025 —; AWS sigue anunciada para fines de 2026. Eso resuelve la residencia de datos para el grueso de la plataforma; qué modelos de Foundry se sirven desde ahí se verifica aparte. Y el matiz Azure: la capacidad de modelos por región y tipo de despliegue es un tema real de planificación (módulo 7). Y la responsabilidad compartida no cambia de logo: lo que tu agente hace es tuyo, con cualquier servicio, en cualquier nube — tercera vez que se dice en la serie, porque es la fila que más se olvida.

Errores comunes

Empezar por los recursos ignorando el tenant. En Azure, los permisos, los grupos de aprobadores y las políticas nacen del directorio. Diseñar la plataforma sin hablar con quien administra Entra ID es construir sobre terreno ajeno.
Una suscripción para todo. El mismo error de la mega-cuenta AWS: radio de explosión total y cuotas compartidas. Prod separada como mínimo, siempre.
Ignorar el resource group como unidad de diseño. Recursos del mismo agente regados en RGs genéricos pierden la gracia del ciclo de vida común (desplegar, permisos, borrar juntos). RG por agente: es gratis y ordena todo lo que viene.
Confundir los niveles. La suscripción aísla facturación y cuotas; el RG agrupa ciclo de vida. “¿Suscripción por agente?” es casi siempre sobre-aislamiento; “¿un RG para toda prod?” es sub-organización. Dos niveles, dos preguntas.
Adoptar la landing zone enterprise del CAF para un piloto. El manual trae la versión de 500 personas. Las escalas del curso (piloto → producción → plataforma) aplican también a cuánta landing zone comprar.

La frase para llevarse

“En Azure, primero existe el directorio y después la nube: el tenant manda, la suscripción aísla facturación y cuotas, el resource group agrupa lo que nace y muere junto, y Azure Policy hereda el techo. Quien entiende esos cuatro niveles ya leyó el mapa — el resto del curso es poblarlo.”

Qué viene

Módulo 2: identidad — managed identities y el agente en el directorio. La inversión filosófica del tenant se vuelve concreta: el agente como managed identity (la identidad sin credenciales que Azure administra sola), RBAC sobre la jerarquía que acabamos de ver, y la ventaja diferencial de Azure — el agente y el humano que lo aprueba viviendo en el mismo directorio.

Arquitectura Azure — Módulo 1: el mapa de Azure