En la lección anterior creaste un grupo de recursos y una cuenta de almacenamiento haciendo clics, y quedaron preguntas en el aire: ¿qué es realmente un grupo de recursos? ¿Por qué borrarlo elimina todo lo que contiene? ¿Por qué las etiquetas no se heredan? ¿Y cómo es posible que el portal, la línea de comandos y una plantilla hagan exactamente lo mismo?

La respuesta a todas es la misma: Azure Resource Manager (ARM), el plano de control de Azure. Entender ARM es lo que separa a quien "sabe usar el portal" de quien entiende Azure. Esta lección es la más importante del módulo desde el punto de vista conceptual, y sus consecuencias prácticas —organización, gobierno, coste, protección de producción— te acompañarán hasta el último módulo.

1. Qué es Azure Resource Manager
2. La jerarquía completa de Azure
3. Proveedores de recursos y su registro
4. El ID de recurso y cómo leerlo
5. Criterios reales para agrupar recursos
6. Bloqueos de recurso: proteger producción
7. Mover recursos entre grupos y suscripciones
8. Etiquetas: para qué sirven de verdad
9. El esquema de etiquetado de Contoso Airlines
10. Plantillas ARM y Bicep como concepto
11. Límites y cuotas de suscripción
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

Azure Resource Manager es el servicio de gestión de Azure: la única puerta por la que pasan todas las operaciones de creación, modificación, lectura y eliminación de recursos. No es una herramienta que uses directamente; es la API que hay detrás de todas las herramientas.

Consecuencias prácticas de este diseño, todas comprobables:

• Coherencia total. Lo que puedes hacer por el portal puedes hacerlo por CLI, y viceversa. Si algo aparece en una herramienta y no en otra, suele ser cuestión de versión, no de capacidad.
• Un solo punto de seguridad. Los permisos RBAC (módulo 4) y las políticas (módulo 4) se aplican en ARM, así que valen para todas las herramientas por igual. No puedes "esquivar" una política usando la CLI.
• Auditoría unificada. El registro de actividad que viste en la lección anterior recoge las operaciones vengan de donde vengan.
• Despliegues declarativos. ARM acepta plantillas que describen el estado deseado, resuelve el orden de creación y paraleliza lo que puede.
• Operaciones idempotentes. Enviar dos veces el mismo estado deseado no crea dos recursos: converge al mismo resultado. Esta propiedad es la base de la infraestructura como código.

Un matiz que evita confusiones futuras: ARM gobierna el plano de control (crear una cuenta de almacenamiento, cambiar su nivel). El plano de datos (subir un blob, ejecutar una consulta SQL) lo atiende cada servicio con su propio extremo y sus propios permisos. Dos planos, dos modelos de acceso.

Cuatro niveles, de mayor a menor alcance. Cada uno tiene un propósito distinto y es donde se aplican determinadas cosas.

Reglas de hierro que hay que memorizar:

1. Todo recurso pertenece a exactamente un grupo de recursos, y este a exactamente una suscripción.
2. Los permisos y las políticas se heredan hacia abajo. Un permiso concedido en la suscripción se aplica a todos sus grupos y recursos.
3. Las etiquetas NO se heredan. Insisto porque es contraintuitivo justo por el punto anterior. Lo veremos en el apartado 8.
4. Un grupo de recursos puede contener recursos de regiones distintas. Su propia región solo dice dónde se guardan los metadatos del grupo.
5. Borrar un grupo de recursos borra todo su contenido, sin excepción y sin papelera.

Sobre los grupos de administración: Contoso todavía no los necesita con dos suscripciones, pero son la herramienta correcta en cuanto haya varias. Permiten, por ejemplo, aplicar una política de "solo se puede desplegar en regiones europeas" a todo lo que cuelgue del grupo Producción, sin repetirla suscripción a suscripción. Se desarrollan en la lección 04-06 (Azure Policy).

Un proveedor de recursos (resource provider) es el componente de ARM que sabe crear y gestionar una familia de recursos. Su nombre tiene la forma Microsoft.<Familia>:

Cada proveedor debe estar registrado en la suscripción para poder usarlo. El portal registra automáticamente el proveedor cuando creas el primer recurso de esa familia, por eso normalmente ni te enteras. Pero cuando despliegas por CLI o con una plantilla, un proveedor sin registrar produce un error críptico del tipo "The subscription is not registered to use namespace 'Microsoft.X'".

Los proveedores también determinan qué versiones de API están disponibles y en qué regiones existe cada tipo de recurso:

Cada recurso de Azure tiene un identificador único y global. Aparece en los registros, en los mensajes de error, en las plantillas y en cualquier automatización, así que hay que saber leerlo de un vistazo.

Desglose por segmentos:

Los recursos hijos anidan el patrón. Una base de datos dentro de un servidor SQL:

Y algunos recursos viven directamente en la suscripción, sin grupo (por ejemplo, una asignación de política a nivel de suscripción):

Obtener el ID de un recurso desde la CLI:

La pregunta que todo el mundo hace: "¿cuántos grupos de recursos creo y qué pongo en cada uno?". La respuesta profesional no es "uno por proyecto" sin más.

Pon en el mismo grupo lo que nace y muere junto. Si vas a borrar la aplicación de reservas, ¿quieres que desaparezca también la red virtual corporativa? No. Entonces no van en el mismo grupo.

• "Todo junto": un único grupo con 300 recursos. Imposible de dar permisos con criterio, imposible de borrar nada con seguridad.
• "Uno por recurso": 300 grupos con un recurso cada uno. Toda la sobrecarga de gestión y ninguna de las ventajas.
• "Por tipo de recurso": un grupo para todas las VM, otro para todas las bases de datos. Suena ordenado y es un desastre: nada comparte ciclo de vida y no puedes borrar un proyecto sin ir pieza a pieza.

Los tres últimos se irán poblando en los módulos 2, 4 y 7. Fíjate en que la red está separada: es exactamente el tipo de recurso compartido y duradero que no debe morir con una aplicación.

Un bloqueo (lock) impide operaciones destructivas incluso a quien tiene permisos de propietario. Es la red de seguridad contra el error humano, no contra el ataque.

Se pueden aplicar a suscripción, grupo de recursos o recurso individual, y se heredan hacia abajo: un bloqueo en el grupo protege a todos sus recursos.

Desde el portal: recurso o grupo → Bloqueos → Agregar.

ReadOnly es más agresivo de lo que parece y provoca sorpresas:

• Un ReadOnly sobre un grupo con una cuenta de almacenamiento impide listar las claves de acceso, porque esa operación es técnicamente una escritura (listKeys). Aplicaciones que funcionaban dejan de funcionar.
• Un ReadOnly sobre una máquina virtual impide iniciarla o detenerla.
• Los bloqueos afectan al plano de control, no al de datos: con CanNotDelete sobre una cuenta de almacenamiento, nadie puede borrar la cuenta, pero cualquiera con permisos de datos sí puede borrar los blobs de dentro. Para eso existen otras protecciones (retención, eliminación temporal), que se ven en el módulo 2.

Práctica recomendada en Contoso: CanNotDelete en todos los grupos de producción y en los recursos con estado (bases de datos, cuentas de almacenamiento, Key Vault). ReadOnly solo en casos muy justificados y con pruebas previas.

Los recursos se pueden mover, pero con reglas. Es una operación habitual cuando reorganizas o cuando un proyecto pasa de desarrollo a producción.

• No todos los recursos se pueden mover. Existe una lista oficial por tipo de recurso; comprueba siempre antes. Ejemplos habituales de restricción: puertas de enlace de VPN, algunas configuraciones de red y ciertos recursos con dependencias regionales.
• Mover no cambia la región. Un recurso en West Europe sigue en West Europe aunque lo muevas a un grupo cuya región sea otra. Para "moverlo de región" hay que recrearlo o replicarlo.
• Durante el movimiento, el grupo de origen y el de destino quedan bloqueados para escritura hasta que termine.
• Hay que mover los recursos dependientes juntos. Una VM necesita ir con su interfaz de red, sus discos y su IP pública.
• Los identificadores cambian, porque el ID incluye el grupo. Cualquier script, alerta o asignación de política que apunte al ID antiguo dejará de funcionar.
• Las asignaciones de permisos y las políticas no viajan con el recurso: se aplican las del nuevo ámbito. Revisa el acceso después de mover.
• Mover entre suscripciones exige además que ambas estén en el mismo inquilino de Microsoft Entra ID y que los proveedores estén registrados en la de destino.

Consejo práctico: en un movimiento importante, valida primero:

Una etiqueta (tag) es un par nombre-valor que se adjunta a una suscripción, un grupo de recursos o un recurso. Cada recurso admite hasta 50 etiquetas.

Las etiquetas parecen un adorno hasta que la empresa tiene 400 recursos. Entonces se convierten en la única forma de responder a preguntas críticas:

Es decir: coste, propiedad y cumplimiento. Sin etiquetas, la conversación del módulo 8 con Nuria Peña ("¿por qué gastamos 4.000 € este mes?") es imposible de mantener, porque Cost Management sabrá decirte que gastas en máquinas virtuales, pero no de quién son.

Las etiquetas no se heredan. Una etiqueta puesta en un grupo de recursos no aparece en los recursos que contiene. Es la trampa número uno de Azure para quien viene del portal, porque todo lo demás (permisos, políticas, bloqueos) sí se hereda.

¿Por qué importa tanto? Porque los informes de coste se agregan por la etiqueta del recurso que genera el cargo. Si etiquetaste solo el grupo, tus informes por centro-coste saldrán vacíos.

Las tres soluciones reales:

1. Etiquetar en la creación, siempre, en la pestaña Etiquetas o con el parámetro --tags. Es la disciplina básica.
2. Azure Policy con efecto Modify: una política que añade automáticamente al recurso la etiqueta heredada del grupo. Es la solución profesional y se ve en la lección 04-06.
3. Infraestructura como código: las etiquetas van escritas en la plantilla y se aplican solas en cada despliegue (lección 05-06).

Otros detalles operativos:

• Los nombres de etiqueta no distinguen mayúsculas de minúsculas para las operaciones, pero los valores sí las conservan tal cual los escribes. Elige un formato y respétalo: produccion y Produccion se contarán como valores distintos en los informes.
• No pongas secretos en etiquetas: son visibles para cualquiera con permiso de lectura.
• Algunos tipos de recurso no admiten etiquetas; son minoría, pero existen.

Salida típica del último comando:

Y en el portal: recurso o grupo → sección Etiquetas → añadir pares nombre/valor → Aplicar. Para etiquetar muchos recursos a la vez, usa Todos los recursos, marca las casillas y pulsa Asignar etiquetas.

Marta Ríos publica este esquema como norma interna. Es obligatorio en todos los recursos y lo usaremos durante todo el curso.

Reglas del esquema:

1. Todos los valores en minúsculas y sin acentos, para que los informes agrupen bien.
2. propietario es siempre una persona, no un departamento: los departamentos no responden al teléfono.
3. Los recursos sin las cuatro etiquetas obligatorias se marcan como no conformes y aparecerán en el informe de cumplimiento cuando implantemos Azure Policy (lección 04-06).

Aplicado a los recursos que ya conoces:

Ya sabes que ARM acepta descripciones declarativas del estado deseado. Esas descripciones son las plantillas ARM (JSON) y Bicep (un lenguaje más legible que se compila a JSON). Aquí solo el concepto: el desarrollo completo está en la lección 05-06.

Una plantilla ARM en JSON, reducida a lo mínimo:

Lo mismo en Bicep, mucho más legible:

Tres ideas para quedarse:

• Es declarativo: describes el resultado, no los pasos. ARM calcula qué hay que crear, modificar o dejar igual.
• Es idempotente: desplegar cinco veces deja el mismo resultado que desplegar una.
• Es versionable: la plantilla vive en Git, se revisa en un pull request y se despliega desde una tubería (módulo 5).

Truco de aprendizaje que ya viste en el portal: en cualquier recurso, sección Automatización → Exportar plantilla, obtienes el JSON del recurso existente. Es la mejor forma de aprender la sintaxis a partir de algo que ya funciona.

Azure no es infinito. Cada suscripción tiene límites (algunos fijos, otros ampliables abriendo una solicitud de soporte). Enterarse de un límite en mitad de un despliegue urgente es una experiencia desagradable y evitable.

Las cifras exactas cambian; consulta siempre "Suscripción de Azure y límites, cuotas y restricciones del servicio" en la documentación oficial.

La cuota que más problemas da a los principiantes es la de núcleos de VM por región y familia: una cuenta gratuita nueva puede tener margen para muy pocas máquinas, y el error al desplegar ("Operation could not be completed as it results in exceeding approved quota") desconcierta porque parece un fallo del despliegue y no lo es.

Consultar tu cuota real:

Para ampliar cuota: portal → Suscripciones → tu suscripción → Uso + cuotas → Solicitar aumento. Suele resolverse en minutos u horas.

• Crear un grupo de recursos "cajón de sastre". Si no sabes por qué un recurso está ahí, está mal ubicado. Agrupa por ciclo de vida.
• Creer que las etiquetas se heredan. No se heredan. Etiqueta cada recurso en la creación o automatízalo con Azure Policy.
• Etiquetar con valores inconsistentes. Produccion, produccion, PRO y prod son cuatro valores distintos en los informes de coste, y el informe queda inservible. Fija el vocabulario y respétalo.
• Poner ReadOnly alegremente. Puede romper aplicaciones al impedir operaciones que parecen de lectura pero son de escritura (como listar claves). Prueba primero en desarrollo.
• Confiar en CanNotDelete para proteger datos. Protege el recurso, no su contenido. Los blobs de dentro se pueden borrar igualmente.
• Mover recursos sin comprobar la lista de soportados ni avisar de que los IDs cambiarán. Revisa después las alertas, los scripts y los permisos.
• Ignorar el registro de proveedores al automatizar en una suscripción nueva. Registra los proveedores al principio del script.
• Descubrir la cuota de núcleos en mitad de un despliegue. Consúltala antes con az vm list-usage.
• Consejo de coste: los grupos de recursos, las etiquetas y los bloqueos son gratuitos. Úsalos sin miedo: son la infraestructura de gobierno más barata que existe y la que más dinero ahorra a medio plazo.

Contoso Airlines va a lanzar además un programa de fidelización ("Contoso Millas"), con su propia web, su base de datos y su centro de coste CC-2077, propiedad de Diego Salas. Compartirá la red virtual corporativa y el Key Vault existentes.

1. Propón los grupos de recursos necesarios y qué contiene cada uno.
2. Justifica por qué la red virtual no debe estar en el grupo del proyecto.
3. Escribe el conjunto de etiquetas obligatorias para el grupo de producción de Contoso Millas.

1. Descompón este ID en sus cinco partes e indica qué es cada una:

2. Construye el ID que tendría una subred llamada snet-web dentro de esa misma red virtual.
3. Escribe el comando de la CLI que devuelve solo el ID de la cuenta de almacenamiento sttarjetascontosopro del grupo rg-contoso-reservas-pro.

1. Escribe los comandos para crear el grupo rg-contoso-reservas-pro en West Europe con las cuatro etiquetas obligatorias y aplicarle un bloqueo CanNotDelete.
2. Escribe el comando que lista todos los recursos de la suscripción etiquetados con proyecto=contoso-reservas.
3. Marta intenta borrar el grupo desde el portal y falla. Explica qué ocurre y qué debe hacer para conseguirlo legítimamente.
4. Diego pone ReadOnly sobre el grupo de desarrollo y, al día siguiente, la aplicación de pruebas deja de arrancar porque no puede leer las claves de la cuenta de almacenamiento. Explica por qué.

Solución 1:

1. Grupos propuestos:

2. La red virtual tiene un ciclo de vida distinto: sobrevive a los proyectos y la comparten varias aplicaciones. Si viviera dentro del grupo del proyecto, al retirar Contoso Millas se borraría la red de todos, y además habría que dar a los desarrolladores permisos sobre un recurso de infraestructura que no deben administrar.

3. Etiquetas del grupo de producción de Millas:

Solución 2:

1. Descomposición:

2. ID de la subred (recurso hijo, se anida tipo/nombre):

3. Comando:

Solución 3:

1. Creación y bloqueo:

2. Listado por etiqueta:

3. El bloqueo CanNotDelete impide la eliminación aunque Marta sea propietaria. Para borrarlo legítimamente debe primero eliminar el bloqueo (az lock delete o portal → Bloqueos), lo que exige permiso sobre Microsoft.Authorization/locks, y después borrar el grupo. Ese paso extra, deliberadamente incómodo, es exactamente el punto: obliga a una decisión consciente.

4. Porque ReadOnly bloquea cualquier operación de escritura en el plano de control, y obtener las claves de una cuenta de almacenamiento se implementa como la acción listKeys, que ARM clasifica como escritura. La aplicación no puede recuperar las claves y falla al arrancar. Solución: retirar el ReadOnly (usar CanNotDelete en su lugar) y, mejor aún, dejar de usar claves y pasar a identidades administradas (lección 04-02).

Azure Resource Manager es el plano de control único de Azure: portal, CLI, PowerShell, SDK y plantillas hablan con la misma API, y por eso los permisos, las políticas y la auditoría son coherentes vengas de donde vengas. Sobre él se apoya la jerarquía grupo de administración → suscripción → grupo de recursos → recurso, donde los permisos y las políticas se heredan hacia abajo... y las etiquetas no.

Has aprendido a leer un ID de recurso, a registrar proveedores, a agrupar recursos por ciclo de vida y entorno (evitando el "todo junto" y el "uno por tipo"), a proteger producción con bloqueos —conociendo las trampas de ReadOnly y los límites de CanNotDelete—, a mover recursos sabiendo que los IDs cambian y que los permisos no viajan, y a diseñar un esquema de etiquetado serio: el de Contoso Airlines, con entorno, proyecto, centro-coste y propietario como obligatorias. También has visto de qué van las plantillas ARM y Bicep, y dónde están los límites y cuotas que conviene mirar antes y no después.

Has notado que en esta lección los ejemplos ya eran, casi todos, comandos. No es casualidad: gobernar decenas de recursos con etiquetas y bloqueos a base de clics no escala. En la última lección del módulo, Azure CLI, PowerShell y Cloud Shell, aprenderás a manejar Azure desde la línea de comandos y escribirás tu primer script completo, parametrizado e idempotente, que crea toda la base de Contoso Airlines y sabe limpiarse después.