Los cuatro eslabones — atribuir, ver, alertar, frenar — cierran su gira: la doctrina en AWS, la estructura que atribuye sola en GCP, y ahora las piezas de Azure, donde la ventaja local está en el primer eslabón (la política que obliga) y el freno duro viene incorporado en cómo se consumen los modelos.

Eslabón	En AWS	En GCP	En Azure
Atribuir	Tags (+ activar)	Proyecto + labels	Tags + RG (+ Azure Policy que los exige)
Atribuir tokens	Inference profiles	Proyecto por agente	Despliegue por agente/caso
Ver	Cost Explorer	Billing export a BigQuery	Cost Management (+ exports)
Alertar	Budgets 50/80/100	Presupuestos → Pub/Sub	Budgets → action groups
Frenar selectivo	Budget action (deny IAM)	Función quita binding	Action group → runbook/function
Freno de fábrica	(rate limits propios)	Cuotas de API	TPM por despliegue

La tesis del módulo

Azure aporta dos comodidades a la cadena: Azure Policy convierte el etiquetado de sugerencia en requisito — el recurso sin tag no se despliega, fin de la disciplina voluntaria — y el TPM por despliegue del módulo 7 significa que el freno duro del consumo de modelos ya existe como propiedad del objeto desplegado, no como proyecto aparte. El resto se ensambla: budgets que disparan action groups, action groups que ejecutan el freno selectivo — la tubería de GCP con nombres de esta casa.

Atribuir: la política que obliga

Los tags de Azure funcionan como los de AWS (diccionario corto: caso/agente, entorno, equipo — aplicados por Terraform) con dos ventajas locales. Primera: el resource group por agente del módulo 1 ya agrupa el gasto de cada agente — el reporte por RG es la atribución gruesa gratis, el eco débil del proyecto-de-GCP (débil porque los servicios compartidos y los tokens piden más). Segunda, la diferencial: Azure Policy puede exigir tags — denegar la creación de recursos sin caso y entorno, o heredarlos del RG automáticamente. La fragilidad del eslabón uno en AWS (“etiquetar después” = nunca) tiene aquí su solución estructural: la política se declara una vez en el management group y el etiquetado deja de depender de la memoria de nadie.

Para los tokens, el módulo 7 dejó la unidad lista: el despliegue por agente/caso — cada uno con sus tags — parte el gasto de Foundry por la dimensión que el showback necesita, jugando el papel exacto de los inference profiles de AWS.

Ver y alertar: Cost Management y la tubería

Cost Management es el explorador (vistas por tag, RG, suscripción, servicio) con exportaciones programadas a Storage para el análisis serio — el JOIN costo-por-tarea del caso de uso se arma sobre esas exportaciones más tus métricas de volumen (una pieza más de plomería que en GCP, como anticipó el módulo 6; el destino natural del cruce es el mundo Fabric o tu Postgres de análisis). Las cuatro preguntas de madurez de la serie no cambian; la detección de anomalías existe y se activa; y los budgets alertan por umbral — 50/80/100 con dueño, la escalera de siempre — con la pieza de acción local: el action group.

Frenar: action groups y el freno que vino de fábrica

El action group es el despachador de respuestas de Azure Monitor: ante la alerta (de budget, de métrica, de log) ejecuta — correo/SMS, webhook, Azure Function, runbook de Automation. La tubería del freno selectivo se arma igual que en GCP:

   EL FRENO EN CAPAS (AZURE)

  capa 1 · de fábrica y por diseño
    TPM por despliegue (mód. 7) · KEDA con tope
    de réplicas (mód. 3) · APIM token limits ·
    reintentos con tope (mód. 5)
                 │ si algo se escapa
                 ▼
  capa 2 · budget 50%/80% → action group avisa
                 │ si sigue
                 ▼
  capa 3 · budget 100% → action group ejecuta
    function: quitar el role assignment del
    agente desbocado / TPM del despliegue a
    mínimo — los demás siguen
                 │ anomalía global
                 ▼
  capa 4 · emergencia manual con runbook

La observación que corona la serie: en Azure, la capa 1 es la más equipada de las tres nubes — el TPM por despliegue acota el consumo de modelos del agente por construcción, APIM suma límites de tokens por consumidor si está en el camino, y KEDA lleva tope de réplicas. El bucle desbocado choca con tres muros antes de que la factura se entere — que es exactamente donde los muros sirven, porque la letra chica del billing no cambió de nube: los datos de costos llegan con horas de rezago en Azure también, y el freno de facturación sigue siendo para la sangría lenta, jamás para la hemorragia.

Ojo — el freno selectivo necesita la unidad selectiva: quitar el rol o bajar el TPM del agente desbocado sin tocar al resto presupone las decisiones de los módulos 1-2-7: RG por agente, managed identity por agente, despliegue por agente. Si tres agentes comparten identidad y despliegue, el freno disponible es el garrote. Tercera nube diciendo lo mismo: la granularidad del freno se compra en el diseño, no en la emergencia.

Errores comunes

Tags voluntarios teniendo Azure Policy. La nube donde el etiquetado puede ser obligatorio es la nube donde no hay excusa para el recurso huérfano. La política de tags requeridos se declara en el management group el día uno.
Un despliegue de modelo para toda la empresa. El gasto de Foundry en una línea = showback imposible y freno selectivo inexistente. Despliegue por agente/caso, con sus tags.
Budgets que solo mandan correo. El action group existe para ejecutar; dejarlo en notificación es la capa 2 vestida de sistema. La function del freno selectivo es una tarde de trabajo.
Repartir TPM y olvidarlo. Las cuotas por despliegue se revisan con el volumen real — el agente que creció choca con su TPM y parece “degradación del modelo” cuando es éxito no re-dimensionado.
Esperar el billing para el bucle rápido. Horas de rezago en las tres nubes. Los primeros minutos son del TPM, los topes y las alarmas operativas del módulo 11.
El JOIN pendiente para siempre. Exportaciones activadas, métricas emitidas, y el costo-por-tarea real jamás calculado. El business case del caso sigue esperando su verificación — en cualquier nube.

La frase para llevarse

“Azure te deja hacer el etiquetado obligatorio por política y te entrega el freno de modelos incorporado al despliegue — así que la cadena completa queda: tags que nadie puede omitir, despliegue por agente que atribuye y acota, budget que dispara el action group, y la granularidad del freno comprada donde siempre: en el diseño.”

Qué viene

Empieza el bloque avanzado con el módulo 9: Foundry Agent Service y el stack de agentes de Microsoft — el Agent Service como runtime que orquesta conversaciones, herramientas y content safety; Foundry IQ como capa de grounding; el control plane que gobierna la flota — mapeado contra AgentCore y Agent Engine, con la decisión pieza-por-pieza de la serie ejecutada por tercera vez.

Arquitectura Azure — Módulo 8: FinOps de la plataforma