Problema

Muchos profesionales que migran de AWS a Azure se topan con una sorpresa: no basta con traducir nombres de servicios (EC2 → VM, S3 → Blob). El verdadero reto está en la forma en que Azure estructura la administración y la gobernanza. En AWS, la cuenta es el límite principal: facturación, cuotas, permisos y aislamiento se definen allí. En Azure, esa frontera se fragmenta en varios niveles (Tenant, Management Groups, Subscription, Resource Group) y cada uno puede recibir políticas o RBAC que se heredan hacia abajo. Cuando el equipo sigue pensando en “cuenta” como única zona de control, aparecen problemas de sobre‑permisos, facturación inesperada y dificultades para aplicar normas de compliance.

Causa

  1. Confusión entre identidades y recursos – El Azure Tenant es principalmente un contenedor de identidades (Microsoft Entra). Si se equipara directamente con AWS Organization, se ignora que las políticas de gobernanza se aplican en los Management Groups, no en el Tenant.
  2. Falta de un nivel intermedio de agrupación – En AWS la jerarquía termina en la cuenta; en Azure el Subscription actúa como esa capa, pero encima existen Management Groups que permiten agrupar varias Subscriptions bajo una política común. Omitir este nivel lleva a crear políticas duplicadas o a aplicar restricciones demasiado amplias.
  3. Uso incorrecto de Resource Groups – En AWS los “resource groups” son meras etiquetas visuales. En Azure, cada recurso debe pertenecer a un Resource Group, y ese grupo define el ciclo de vida y el scope de RBAC. El error típico es crear un Resource Group por proyecto y luego intentar mover recursos entre grupos sin considerar que la eliminación del grupo borra todo lo que contiene.
  4. Herencia inesperada de RBAC – Los permisos pueden asignarse en cualquier nivel de la jerarquía. Si se otorgan derechos a nivel de Management Group, todos los Subscriptions y Resource Groups bajo él heredan esos permisos, lo que puede generar accesos innecesarios si no se controla la herencia.

Solución

Adoptar un modelo de diseño que refleje la jerarquía nativa de Azure y que permita mapearlo a la mentalidad de AWS. El proceso se divide en tres fases:

1. Definir el Tenant y los Management Groups

  • Tenant: Mantenerlo exclusivamente para la gestión de identidades (usuarios, grupos, aplicaciones). No colocar políticas de recursos aquí.
  • Management Groups: Crear una estructura que refleje la organización empresarial (por ejemplo, Corp, DivisionA, DivisionB). Cada grupo recibe políticas de compliance (Azure Policy, Azure Blueprints) que se propagan a sus Subscriptions. Evitar crear más de tres niveles profundos para no complicar la herencia.

2. Planificar Subscriptions por frontera de facturación y aislamiento

  • Subscription: Asignar una Subscription por unidad de facturación o por zona de aislamiento (producción vs. desarrollo, región geográfica, cliente externo). Cada Subscription hereda las políticas del Management Group pero mantiene sus cuotas y límites de facturación independientes.
  • Configurar Azure Cost Management a nivel de Subscription para obtener visibilidad similar a la de una AWS Account.

3. Organizar recursos en Resource Groups con lógica de ciclo de vida

  • Resource Group: Usar una convención de nombres que incluya entorno, aplicación y región (p.ej., rg-app1-prod-eastus). Cada grupo agrupa recursos que comparten el mismo ciclo de vida (despliegue, actualización, eliminación).
  • Asignar RBAC a nivel de Resource Group para equipos de desarrollo, mientras que los administradores de plataforma reciben permisos a nivel de Subscription o Management Group.
  • Aplicar Azure Policy en el nivel de Resource Group cuando se necesiten restricciones específicas (por ejemplo, tipos de VM permitidos).

4. Documentar la herencia y validar permisos

  • Generar un diagrama que muestre la cadena de herencia: Tenant → Management Group → Subscription → Resource Group → Resource.
  • Utilizar az role assignment list para exportar los permisos actuales y comparar con la política deseada.

Cuándo aplicar esta solución

  • Migraciones de AWS a Azure donde el equipo ya está acostumbrado a trabajar con cuentas como límite de control.
  • Entornos multi‑cliente o multi‑proyecto que requieren aislamiento de facturación y cumplimiento regulatorio.
  • Implementaciones de governance que usan Azure Policy o Blueprints y necesitan una capa de aplicación coherente.
  • Escenarios donde la eliminación masiva de recursos (por ejemplo, pruebas temporales) debe ser segura y predecible.

No es adecuada cuando:

  • La organización es extremadamente pequeña (una sola Subscription) y no necesita Management Groups.
  • Se trabaja exclusivamente con recursos de prueba que no requieren control de ciclo de vida.

Código

# Listar todas las asignaciones de RBAC en un Management Group
az role assignment list --scope /providers/Microsoft.Management/managementGroups/Corp

# Exportar políticas aplicadas a una Subscription
az policy state list --subscription 00000000-1111-2222-3333-444444444444 > policies.json

# Crear un Resource Group con etiquetas de entorno y aplicación
az group create \
  --name rg-app1-prod-eastus \
  --location eastus \
  --tags env=prod app=app1

Verificación

  1. Revisar herencia: Ejecutar az role assignment list --scope <resource-id> en un recurso y confirmar que los permisos provienen del nivel esperado (Resource Group, Subscription o Management Group).
  2. Validar políticas: Usar az policy state list --resource <resource-id> para asegurarse de que el recurso cumple con las políticas heredadas.
  3. Control de costos: En Azure Cost Management, filtrar por Subscription y comparar con los costos esperados de la cuenta AWS equivalente.
  4. Prueba de eliminación: Eliminar un Resource Group de prueba y verificar que todos los recursos contenidos desaparecen sin afectar otros grupos.

Notas adicionales

  • Naming conventions: Un esquema de nombres consistente reduce errores al mover recursos entre grupos o Subscriptions.
  • Limitaciones de herencia: Azure no permite bloquear la herencia de una política en un nivel inferior; la única forma es sobrescribirla con una política de “deny” específica.
  • Auditoría: Habilitar Azure Activity Log a nivel de Tenant garantiza que cualquier cambio de política o asignación de rol quede registrado, facilitando auditorías de compliance.
  • Migración incremental: En vez de mover todos los recursos de una cuenta AWS a una única Subscription, crear Subscriptions por entorno y migrar por fases para validar la configuración de RBAC y políticas antes de escalar.