Fundamentos de Azure: jerarquía de recursos, Entra ID, cómputo, almacenamiento y red

La mayoría de los ingenieros llega a Azure después de haber trabajado con otra nube, y la fricción rara vez es conceptual. Las regiones, las máquinas virtuales, el almacenamiento de objetos y las bases de datos administradas funcionan como esperas. Lo que frena es que Azure tiene un nivel de agrupación adicional que otros proveedores no tienen, un servicio de directorio con su propio modelo de permisos junto al de los recursos, y una convención de nombres en la que la misma palabra significa cosas distintas según el contexto. El objetivo de esta guía es que superes todo eso de una sentada.

Damos por hecho que sabes qué son una región, una zona de disponibilidad y el modelo de responsabilidad compartida; si no, empieza por los fundamentos de la nube. Todo lo que sigue usa los nombres actuales de los servicios; cuando un servicio se ha renombrado hace poco, el nombre antiguo aparece una vez para que la documentación más antigua siga teniendo sentido.

La jerarquía de recursos

Azure organiza todo en cuatro niveles anidados, y saber a qué nivel pertenece cada ajuste te ahorra muchas búsquedas.

Microsoft Entra tenant           límite de identidad — usuarios, grupos, registros de aplicaciones
└── Management group             directivas y acceso heredados por todo lo que hay debajo
    └── Management group (…)     hasta seis niveles de profundidad
        └── Subscription         límite de facturación + límite de cuotas
            └── Resource group   límite de ciclo de vida — se despliega y se borra en bloque
                └── Resource     una VM, una cuenta de almacenamiento, una base de datos

Un tenant es el directorio. Una organización suele tener uno, y es donde viven las identidades; no es donde viven los recursos.

Una suscripción es el contenedor de facturación y el contenedor de cuotas. Cada recurso pertenece exactamente a una. Las organizaciones dividen las suscripciones según lo que quieren facturar, aislar o limitar por separado: producción frente a no producción, una por unidad de negocio, una por plataforma principal. Las cuotas (cuántos núcleos de una familia de VM puedes ejecutar en una región) se aplican por suscripción, que es el motivo práctico para no ejecutarlo todo en una sola.

Un grupo de administración se sitúa por encima de las suscripciones y existe para no tener que repetir la gobernanza. Las asignaciones de Azure Policy y de roles aplicadas a un grupo de administración las heredan todas las suscripciones que cuelgan de él. Una estructura típica tiene un grupo raíz, después grupos para la plataforma y las landing zones, y bajo ellos producción y no producción.

Un grupo de recursos es una carpeta con dientes. Sus recursos pueden desplegarse juntos, etiquetarse juntos, recibir acceso juntos y, lo más importante, borrarse juntos. Agrupa por ciclo de vida, no por tipo de recurso: todo lo que se crea y se destruye como unidad va en el mismo grupo.

Identidad: Microsoft Entra ID y asignaciones de roles

El acceso en Azure tiene dos mitades que los principiantes confunden con frecuencia.

Microsoft Entra ID (antes Azure Active Directory) autentica. Contiene usuarios, grupos, entidades de servicio y registros de aplicaciones, y emite tokens. Los roles de Entra ID (Global Administrator, User Administrator, Application Administrator) gobiernan el propio directorio: quién puede crear usuarios, dar consentimiento a aplicaciones o restablecer contraseñas.

Azure RBAC autoriza acciones sobre los recursos. Una asignación de roles une tres cosas: una entidad de seguridad (usuario, grupo, entidad de servicio o identidad administrada), una definición de rol (un conjunto de operaciones permitidas como Contributor, Reader o Storage Blob Data Reader) y un ámbito (grupo de administración, suscripción, grupo de recursos o un único recurso). Los permisos se heredan hacia abajo, así que una asignación Reader en el ámbito de una suscripción convierte a la entidad en lectora de todo lo que contiene.

Ser Global Administrator en Entra ID no te da, por defecto, ningún permiso sobre los recursos, una separación que sorprende a más de uno durante su primer incidente. A la inversa, un Owner de una suscripción no puede crear usuarios.

La identidad administrada es la función a la que deberías recurrir constantemente. Da a un recurso de Azure una identidad en el directorio que gestiona la plataforma: sin secreto de cliente, sin certificado, sin rotación. Una aplicación web con identidad administrada puede leer un secreto de Key Vault o escribir en una cuenta de almacenamiento sin nada más en su configuración que el nombre de un recurso.

# Conceder a la identidad administrada de una aplicación web acceso de lectura a una cuenta de almacenamiento
appId=$(az webapp identity assign -g rg-orders-prod -n app-orders --query principalId -o tsv)
scope=$(az storage account show -g rg-orders-prod -n storders --query id -o tsv)

az role assignment create \
  --assignee-object-id "$appId" --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" --scope "$scope"

Para cualquier acceso privilegiado, añade Privileged Identity Management para que los roles se activen durante unas horas y con justificación en lugar de tenerlos de forma permanente, y exige autenticación multifactor mediante el acceso condicional. Los principios de diseño más generales se tratan en gestión de identidades y accesos.

Cómputo: cuatro opciones y cómo elegir

Azure tiene muchos servicios de cómputo; en la práctica, casi todas las decisiones se reducen a cuatro.

Las Virtual Machines vienen en familias nombradas según su propósito: B para burstable, D para uso general, E optimizada para memoria, F optimizada para cómputo, L para cargas intensivas en almacenamiento. Los conjuntos de escalado (scale sets) agrupan VM idénticas tras reglas de autoescalado y son la forma de ejecutar una capa basada en VM en producción.

App Service es el camino más rápido a producción para una aplicación web típica. Se ejecuta sobre un App Service Plan, que es la unidad que realmente pagas y la razón de muchos sustos en la factura: el plan se cobra reciba tráfico o no, y varias aplicaciones pueden compartir un mismo plan. Los slots de despliegue te permiten publicar en un slot de staging, calentarlo e intercambiarlo con producción, lo que te da despliegues sin tiempo de inactividad y sin ningún trabajo de infraestructura.

Azure Kubernetes Service ofrece un plano de control administrado sin coste; pagas los nodos. Es la respuesta correcta cuando ya usas Kubernetes o cuando el número de servicios justifica un scheduler, y la equivocada para tres microservicios sin equipo de plataforma. Consulta los fundamentos de Kubernetes antes de comprometerte.

Azure Functions cobra por ejecución en el plan Consumption y escala a cero, a cambio de cold starts. El plan Premium mantiene instancias calientes y ofrece integración con la red virtual; el plan dedicado ejecuta las funciones en un App Service Plan que ya estás pagando.

Cuentas de almacenamiento, niveles y discos

Una cuenta de almacenamiento es un espacio de nombres que contiene hasta cuatro servicios: Blob (objetos), Files (recursos compartidos SMB/NFS), Queue (mensajes sencillos) y Table (filas clave-valor). Casi todo el trabajo nuevo usa Blob Storage, idealmente con el espacio de nombres jerárquico activado si lo van a leer herramientas de analítica.

Dos ajustes dominan la factura y el comportamiento.

Redundancia. LRS guarda tres copias dentro de un único centro de datos. ZRS reparte las copias entre las zonas de disponibilidad de la región y es la opción sensata por defecto para todo lo que esté en producción. GRS y GZRS replican de forma asíncrona a una región secundaria emparejada; las variantes con acceso de lectura (RA-GRS, RA-GZRS) te permiten leer la copia secundaria durante una caída regional.

Nivel de acceso. El nivel Hot cuesta más por gigabyte al mes y menos por lectura; Cool, Cold y Archive invierten esa proporción progresivamente, y Archive exige una rehidratación explícita que tarda horas. Define una directiva de administración del ciclo de vida en lugar de mover blobs a mano.

{
  "rules": [{
    "name": "invoices-lifecycle",
    "enabled": true,
    "type": "Lifecycle",
    "definition": {
      "filters": { "blobTypes": ["blockBlob"], "prefixMatch": ["invoices/"] },
      "actions": { "baseBlob": {
        "tierToCool": { "daysAfterModificationGreaterThan": 30 },
        "tierToArchive": { "daysAfterModificationGreaterThan": 180 },
        "delete": { "daysAfterModificationGreaterThan": 2555 }
      }}
    }
  }]
}

Los discos administrados son independientes de las cuentas de almacenamiento y respaldan las máquinas virtuales. Los niveles van desde Standard HDD, pasando por Standard SSD y Premium SSD, hasta Ultra Disk, donde aprovisionas IOPS y rendimiento con independencia de la capacidad. Premium SSD v2 suele ser la opción con mejor relación calidad-precio para bases de datos en VM.

Bases de datos

Azure SQL Database es la opción relacional administrada por defecto: copias de seguridad automáticas con restauración a un momento dado, parches automáticos y, a elegir, un modelo de compra basado en DTU (una abstracción empaquetada) o el modelo vCore (núcleos y memoria explícitos, y el único que admite Azure Hybrid Benefit para licencias existentes). El nivel serverless pausa automáticamente una base de datos inactiva, algo excelente para entornos de desarrollo. Azure Database for PostgreSQL y for MySQL ofrecen el mismo tratamiento administrado para motores open source.

Azure Cosmos DB es el servicio NoSQL distribuido globalmente. Lo distinguen las escrituras multirregión listas para usar y cinco niveles de coherencia explícitos entre fuerte y eventual, que te permiten equilibrar a conciencia latencia frente a datos desactualizados. La capacidad se aprovisiona en unidades de solicitud por segundo, fijas o con escalado automático, o se factura por solicitud en modo serverless. Cosmos DB premia un modelo de datos diseñado en torno a patrones de acceso conocidos y castiga las consultas entre particiones; elígelo para ese tipo de carga, no como sustituto de propósito general de SQL.

Azure Cache for Redis cubre la caché y el estado de sesión, y Azure Service Bus la mensajería duradera con colas y topics cuando necesitas orden, sesiones o transacciones en lugar de la sencilla Storage Queue.

Redes

Una red virtual (VNet) es un espacio de direcciones privado en una región, dividido en subredes. Dos VNet pueden unirse mediante peering, que no es transitivo: emparejar A con B y B con C no conecta A con C, algo que pilla desprevenido a quien monta una topología hub-and-spoke esperando que el hub enrute automáticamente. En hub-and-spoke se coloca un firewall o un dispositivo virtual de red (NVA) en el hub y se añaden rutas definidas por el usuario para forzar el tráfico a través de él.

Un grupo de seguridad de red (NSG) es una lista con estado de reglas de permitir y denegar, evaluadas por prioridad, que se asocia a una subred o a una interfaz de red. Las reglas pueden hacer referencia a etiquetas de servicio como Storage o AzureMonitor en lugar de rangos IP, y los grupos de seguridad de aplicaciones te permiten escribir reglas sobre grupos lógicos de VM en vez de direcciones.

Los puntos de conexión privados (private endpoints) son el patrón importante para los servicios de plataforma. Por defecto, una cuenta de almacenamiento o una base de datos de Azure SQL tiene un punto de conexión público protegido por claves y reglas de firewall; un punto de conexión privado le da una IP privada dentro de tu VNet, de modo que el tráfico nunca cruza internet. Combínalo con una zona DNS privada para que el nombre de host habitual se resuelva a esa dirección privada.

La conexión con la infraestructura on-premises se hace con una VPN Gateway a través de internet o con ExpressRoute sobre un circuito privado, y el tráfico se reparte con Load Balancer (capa 4), Application Gateway (capa 7, con firewall de aplicaciones web) o Front Door (global, con caché en el edge).

Infraestructura como código con Bicep

Las plantillas ARM son el formato de despliegue JSON subyacente; Bicep es un lenguaje legible que se compila a ellas, y es lo que deberías escribir. No tiene archivo de estado (el grafo de recursos de Azure es el estado) y los despliegues son declarativos e idempotentes.

param location string = resourceGroup().location
param appName string

resource plan 'Microsoft.Web/serverfarms@2023-12-01' = {
  name: '${appName}-plan'
  location: location
  sku: { name: 'P1v3', tier: 'PremiumV3' }
}

resource site 'Microsoft.Web/sites@2023-12-01' = {
  name: appName
  location: location
  identity: { type: 'SystemAssigned' }
  properties: {
    serverFarmId: plan.id
    httpsOnly: true
    siteConfig: {
      linuxFxVersion: 'JAVA|21-java21'
      minTlsVersion: '1.2'
      ftpsState: 'Disabled'
    }
  }
}

output principalId string = site.identity.principalId

az deployment group create \
  --resource-group rg-orders-prod \
  --template-file main.bicep \
  --parameters appName=app-orders \
  --what-if      # previsualizar los cambios antes de aplicarlos

Terraform es igual de viable en Azure y es la mejor opción si también gestionas otros proveedores; el razonamiento está en infraestructura como código.

Vocabulario de AWS a Azure

La correspondencia es aproximada (los equivalentes difieren en capacidades, no solo en nombre), pero acorta la traducción.

Dónde se equivocan los principiantes

Meterlo todo en una sola suscripción. Las cuotas, el ámbito de las directivas y la imputación de costes funcionan a nivel de suscripción. Separar pronto producción de no producción no cuesta nada y te ahorra una migración más adelante.

Dar por hecho que Global Administrator implica acceso a los recursos. No lo implica, y es a propósito. Eleva el acceso de forma explícita y temporal cuando de verdad lo necesites.

Pagar App Service Plans que nadie usa. El plan se cobra de forma continua. Los planes de desarrollo que se quedan encendidos son, con diferencia, la causa más habitual de una factura de Azure inexplicable.

Olvidar que el peering no es transitivo. Los spokes no pueden comunicarse entre sí a través de un hub sin rutas y sin un dispositivo virtual en medio.

Dejar los servicios de plataforma en su punto de conexión público. Las reglas de firewall ayudan, pero los puntos de conexión privados junto con DNS privado son el patrón que esperan los revisores para todo lo que contenga datos regulados.

Conclusiones clave

• Azure anida los recursos en tenant, grupo de administración, suscripción y grupo de recursos; las directivas y las asignaciones de roles se heredan hacia abajo, y el grupo de recursos es la unidad de despliegue y borrado.
• Entra ID autentica y sus roles de directorio gobiernan el directorio; Azure RBAC autoriza las acciones sobre los recursos mediante asignaciones de roles con un ámbito en cualquier punto de la jerarquía.
• Las identidades administradas eliminan por completo las credenciales almacenadas y deberían ser la forma predeterminada en que las cargas de trabajo acceden al almacenamiento, a las bases de datos y a Key Vault.
• Las opciones de cómputo se reducen a VM, App Service, AKS y Functions; en el almacenamiento mandan la redundancia y el nivel de acceso, y las directivas de ciclo de vida deberían mover los datos automáticamente.
• Las VNet, los NSG, el peering no transitivo y los puntos de conexión privados definen la postura de red; Bicep o Terraform deberían describirlo todo como código.