AZ-900

Deep Dive

D2 · Arquitectura y servicios

Jerarquía de recursos Azure

Tenant, Management Groups, Suscripciones, Resource Groups y Recursos — la estructura que organiza todo en Azure. Entenderla es entender el billing, el control de acceso y la gobernanza.

Contenido

Jerarquía completa de Azure
Tenant y Entra ID
Management Groups
Suscripciones — tipos y límites
Resource Groups — mejores prácticas
RBAC aplicado a la jerarquía
Azure Policy y herencia
Tags y Resource Locks

Jerarquía completa de Azure

De arriba a abajo — cada nivel contiene al siguiente y hereda políticas y permisos del nivel superior.

Tenant (Inquilino)

Directorio Entra ID

Instancia de Microsoft Entra ID (antes Azure Active Directory). Representa a tu organización. Un dominio como contoso.com. Todo lo demás vive dentro del tenant.

Clave para el examen

Una empresa = 1 tenant (normalmente). El límite más alto de tu universo Azure.

Root Management Group

Raíz automática

Management Group raíz creado automáticamente al activar Azure. Contiene todos los Management Groups y Suscripciones del tenant. Aplicar política aquí = afecta TODO.

Clave para el examen

Solo el Global Administrator del tenant puede gestionar el Root MG.

Management Groups

Hasta 6 niveles de profundidad

Contenedores de suscripciones para aplicar gobernanza a escala. Políticas y permisos heredan hacia abajo. Máximo 6 niveles de jerarquía. Un MG puede contener otros MGs y suscripciones.

Clave para el examen

Propósito principal: aplicar Azure Policy y RBAC a múltiples suscripciones a la vez.

Suscripción

Unidad de billing y límite de cuota

Unidad de facturación. Cada suscripción = una factura. Tiene límites (quotas) por tipo de recurso. Un tenant puede tener miles de suscripciones. Es el límite de confianza principal de Azure.

Clave para el examen

Suscripción ≠ Tenant. Suscripción es billing. Tenant es identidad.

Resource Group

Contenedor lógico de recursos

Agrupa recursos relacionados para gestión conjunta. Define la región del contenedor (los recursos pueden estar en otras regiones). Eliminar el RG elimina todos sus recursos. Unidad de despliegue típica.

Clave para el examen

Los recursos en un RG deben compartir mismo ciclo de vida — se crean, actualizan y eliminan juntos.

Recursos

VMs, Storage, SQL, etc.

Las entidades individuales de Azure: VMs, discos, bases de datos, redes virtuales, cuentas de almacenamiento. Todo lo que creates en Azure es un recurso. Cada recurso tiene un tipo, nombre, región y suscripción.

Clave para el examen

Cada recurso pertenece exactamente a 1 Resource Group, 1 Suscripción, 1 Región.

Tenant y Microsoft Entra ID

¿Qué es exactamente el Tenant?

Al registrarte en Azure, Microsoft crea automáticamente un Tenant de Entra ID para tu organización. Es el directorio centralizado de identidades. Todos los usuarios, grupos, aplicaciones y permisos de Azure se gestionan aquí.

IdentificadorTenant ID (GUID único) o nombre de dominio (contoso.onmicrosoft.com)

ContenidoUsuarios, grupos, aplicaciones, service principals, dispositivos

AlcancePuede tener suscripciones de múltiples tipos (Pay-As-You-Go, EA, CSP)

Multi-tenantUna app puede ser multi-tenant: acepta usuarios de otros tenants

B2B/B2CEntra ID B2B: invitar usuarios externos. B2C: identidades de consumidores

Entra ID = el cerebro de identidad de Azure

Antes llamado Azure Active Directory (Azure AD). Renombrado a Microsoft Entra ID en 2023. NO confundir con Windows Server Active Directory — son distintos aunque se integran.

AD on-prem vs Entra ID

Windows Server AD: Protocolo LDAP/Kerberos. On-premises. Gestiona computadoras del dominio.

Microsoft Entra ID: Protocolo OAuth/OIDC/SAML. Cloud. Gestiona identidades para apps cloud y SaaS.

Entra ID Connect: Sincroniza usuarios de AD on-prem a Entra ID para SSO híbrido.

Management Groups — gobernanza a escala

Caso real: empresa enterprise con 50 suscripciones

Root Management Group (Contoso)

├── MG: Production

│ ├── Sub: Finance-Prod ($15k/mes)

│ ├── Sub: Sales-Prod ($8k/mes)

│ └── Sub: Operations-Prod ($12k/mes)

├── MG: Non-Production

│ ├── Sub: Dev ($2k/mes)

│ ├── Sub: Staging ($3k/mes)

│ └── Sub: Testing ($1k/mes)

└── MG: Sandbox

└── Sub: Experiments ($500/mes)

Por qué usar Management Groups

Política en MG-Production: Todas las subs de Prod heredan la política. "Todas las VMs deben estar en regiones aprobadas" → aplica a 30 subs de golpe.
RBAC en MG-NonProd: Equipo de QA tiene acceso Contributor a MG-NonProd. Automáticamente tienen acceso a Dev, Staging y Testing subs.
Budget en Sandbox MG: Límite de $500/mes en MG-Sandbox. Ningún experimento puede gastar más sin aprobación.

Límites y restricciones de MGs

10,000Management Groups máximos por tenant

6Niveles de profundidad máximos (sin contar Root)

1Un MG puede tener solo 1 padre

HerenciaPolíticas y RBAC heredan hacia abajo, nunca hacia arriba

Suscripciones — tipos, límites y estrategias

Pay-As-You-Go (PAYG)

Facturación mensual por consumo. Tarjeta de crédito. Sin compromiso. Precio más alto por recurso.

Ideal para

Individuos, startups, pruebas de concepto

Enterprise Agreement (EA)

Contrato de 3 años con Microsoft. Precio negociado (~15-30% descuento). Factura anual. Crédito pre-pagado que se consume.

Ideal para

Empresas con +$100k/año en Azure

Cloud Solution Provider (CSP)

A través de un partner de Microsoft. El partner te factura (no Microsoft directo). Support incluido del partner.

Ideal para

PYMES que quieren soporte local incluido

Razones para tener múltiples suscripciones

Separación de entornos: Prod, Dev, Staging en subs distintas. Evitas que un error en Dev afecte a Prod. Presupuestos separados.

Límites de cuota por suscripción: Max 980 Resource Groups por sub. Max 25k VMs por región por sub. Para workloads masivos, múltiples subs.

Facturación por unidad de negocio: Finance, Sales, IT tienen subs separadas. Cada departamento ve su factura. Chargeback facilitado.

Compliance y aislamiento de datos: Datos regulados (HIPAA, PCI-DSS) en sub separada con políticas más restrictivas. Menos blast radius.

Equipos independientes: Equipo A tiene Owner de su sub. Equipo B de la suya. No interfieren. Autonomía con gobernanza en MG.

Límites de gasto controlados: Budget por suscripción + alertas. Si Dev se pasa, no afecta presupuesto de Prod.

Resource Groups — mejores prácticas

Reglas fundamentales de RGs

Un recurso, un RG: Cada recurso pertenece a exactamente 1 RG. No puedes compartir un recurso entre RGs.
Misma suscripción: Todos los recursos de un RG deben estar en la misma suscripción. No puedes tener recursos de distintas subs en el mismo RG.
Región del RG ≠ región de recursos: El RG tiene una región (donde se almacenan sus metadatos), pero sus recursos pueden estar en diferentes regiones.
Eliminar RG = eliminar todo: Borrar un RG borra TODOS sus recursos permanentemente. Esta es la operación más destructiva en Azure.
RBAC heredado: Permisos asignados a nivel RG aplican a todos los recursos dentro de él.

Estrategias de organización de RGs

Por ambiente (recomendado para la mayoría)

rg-prod-westeurope, rg-dev-eastus, rg-staging-eastus

Equipos medianos. Cada ambiente tiene su RG y su acceso separado.

Por aplicación

rg-webapp-prod, rg-database-prod, rg-api-prod

Múltiples apps independientes. Cada app tiene su ciclo de vida.

Por región

rg-eastus-prod, rg-westeurope-prod

Arquitecturas multi-región donde la localidad de los recursos importa.

Por equipo / departamento

rg-finance-prod, rg-hr-prod, rg-it-prod

Empresas con chargeback por departamento.

RBAC aplicado a la jerarquía

Role-Based Access Control — quién puede hacer qué, en qué scope.

Roles built-in principales del AZ-900

Rol	Puede	No puede	Caso de uso
Owner	Todo: crear, modificar, eliminar recursos Y gestionar acceso	Nada dentro del scope asignado	Responsable de toda una suscripción o RG
Contributor	Crear, modificar, eliminar recursos	Gestionar acceso (no puede dar roles a otros)	Developer que despliega recursos pero no gestiona permisos
Reader	Ver todos los recursos y su configuración	Crear, modificar ni eliminar nada	Auditor, stakeholder que solo necesita visibilidad
User Access Administrator	Gestionar acceso (dar/quitar roles)	Crear o modificar recursos en sí	Equipo de IAM/seguridad que gestiona permisos sin operar recursos

Herencia de RBAC

Los permisos asignados en un nivel SUPERIOR se heredan automáticamente hacia abajo.

Owner en MG-Production

→ Owner en todas las subs de MG-Prod

→ Owner en todos los RGs de esas subs

→ Owner en todos los recursos de esos RGs

Principio de mínimo privilegio

Asigna el rol más restrictivo que permite hacer el trabajo, en el scope más pequeño posible.

Owner en Suscripción completa

Contributor en solo su Resource Group

Contributor para ver logs

Reader en el RG específico

Azure Policy y herencia

Azure Policy vs RBAC — diferencia clave

RBAC — ¿Quién puede hacer qué?

Controla las acciones de los usuarios. "El usuario Juan puede crear VMs" o "María solo puede leer".

Enfoque: identidades y permisos

Azure Policy — ¿Qué configuraciones se permiten?

Controla las propiedades de los recursos. "Las VMs solo pueden crearse en East US" o "Todo recurso debe tener tag 'Owner'".

Enfoque: configuración y compliance de recursos

Efectos de Azure Policy

Deny: Bloquea la creación/modificación si viola la política. Error al intentar crear.

Audit: No bloquea, pero registra una alerta de non-compliance. Para monitoreo sin enforcement.

Append: Añade propiedades adicionales al recurso al crearlo (ej: añadir un tag automáticamente).

DeployIfNotExists: Si el recurso no tiene cierta configuración, la despliega automáticamente.

Modify: Modifica propiedades del recurso al crearlo o actualizarlo.

Tags y Resource Locks

Tags — metadatos de recursos

Pares clave-valor que puedes asignar a recursos y grupos de recursos. Máx 50 tags por recurso.

Usos comunes

Environment: Production

Filtrar recursos por ambiente en Cost Management

Owner: equipo-azure@contoso.com

Saber a quién contactar si hay un problema

CostCenter: IT-0042

Chargeback automático a centros de costo

Project: MigraciónSAP

Agrupar recursos de un proyecto para su facturación

Tags NO se heredan de RG a recursos por defecto. Necesitas Azure Policy para forzar herencia.

Resource Locks — protección contra eliminación

Bloqueos que previenen modificaciones o eliminaciones accidentales. Se aplican a recursos, RGs o suscripciones.

CanNotDelete

Cualquiera puede leer y modificar el recurso, pero nadie puede eliminarlo (sin quitar el lock primero).

Recursos críticos que nunca deben borrarse: storage de prod, SQL de prod.

ReadOnly

Nadie puede modificar ni eliminar el recurso. Solo lectura. Similar a asignar el rol Reader a todos.

Infraestructura de referencia que nunca debe cambiar sin proceso formal.

Los locks se heredan de RG a todos sus recursos. Para quitar un lock, necesitas ser Owner o User Access Administrator.

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

¿En qué nivel de la jerarquía de Azure se deben aplicar políticas para que afecten automáticamente a todas las suscripciones de una organización?