La estimación de la lección anterior decía 17.450 € al mes. La factura de julio de Contoso Airlines dice 17.800 €. Una desviación del 2 % es una estimación excelente, pero ese no es el logro: el logro es que ahora existe una cifra estimada contra la que comparar, y una lista de supuestos que explica cada diferencia. Lo que Nuria Peña necesita a partir de aquí es lo contrario de una hipótesis: qué se gastó de verdad, en qué recurso, de qué equipo, en qué día y por qué sube.

Esa es la función de Microsoft Cost Management, la herramienta gratuita incluida en cualquier suscripción de Azure. Esta lección la recorre entera: la jerarquía de facturación y por qué se confunde siempre con la de recursos, el análisis de costes con sus agrupaciones y su previsión, el desglose real de la factura de Contoso, la diferencia entre coste real y amortizado, los presupuestos con alertas y con respuesta automática, el reparto entre equipos con la etiqueta centro-coste, las exportaciones programadas y la detección de anomalías. Aquí es donde se cobra —con intereses— la disciplina de etiquetado sembrada en el módulo 1 y forzada por la política hereda-centro-coste del módulo 4.

Recordatorio: todas las cifras en euros de esta lección son orientativas y ficticias. Los precios reales de Azure cambian con frecuencia y varían por región, moneda y acuerdo comercial. Consúltalos siempre en la calculadora oficial.

1. La jerarquía de facturación frente a la de recursos
2. Análisis de costes: vistas, agrupaciones y previsión
3. El análisis real de la factura de Contoso
4. Coste real frente a coste amortizado
5. Presupuestos, alertas y grupos de acciones
6. Automatizar la respuesta a un presupuesto superado
7. Asignación de costes: showback, chargeback y lo que no es de nadie
8. Exportaciones programadas y análisis del dato de coste
9. Detección de anomalías
10. Por qué la factura nunca cuadra al céntimo
11. Permisos: quién ve el coste
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

Esta es la confusión clásica, y produce media hora de desconcierto en toda organización que abre Cost Management por primera vez. Hay dos jerarquías distintas, con propósitos distintos, y no se corresponden entre sí.

Los cuatro niveles de facturación, en el caso de Contoso:

• Cuenta de facturación: el contrato con Microsoft. Contoso tiene una, ligada a su Contrato de Cliente de Microsoft.
• Perfil de facturación: la unidad que genera una factura con su propio método de pago y su moneda. Contoso tiene uno, Contoso Airlines Global.
• Sección de factura: la agrupación dentro de la factura, pensada para separar departamentos. Contoso tiene dos: Operaciones de plataforma y Proyectos digitales.
• Suscripción: Contoso Airlines - Producción cuelga de la primera sección; Contoso Airlines - Desarrollo y la de Contoso Millas, de la segunda.

Y la consecuencia práctica que hay que interiorizar: la sección de factura y el grupo de administración son cosas diferentes y pueden no coincidir. Un grupo de administración es un contenedor de gobernanza donde se aplican directivas y RBAC; una sección de factura es una línea en un documento contable. Contoso los mantuvo alineados a propósito para no volverse loca, pero nada obliga a ello, y en organizaciones grandes divergen. Si alguien pregunta «¿por qué el grupo de administración Contoso-Produccion no aparece en la factura?», la respuesta es: porque la factura no sabe que existe.

El análisis de costes es la pantalla central de Cost Management. Se abre desde una suscripción, un grupo de recursos, un grupo de administración o el propio perfil de facturación, y el ámbito elegido gobierna todo lo que se ve.

Los controles que importan:

Las tres vistas que Contoso tiene guardadas y consulta cada semana:

1. vista-coste-diario-produccion: granularidad diaria, agrupada por servicio, ámbito Contoso Airlines - Producción. Es la que revela un salto el día exacto en que ocurre, y por tanto la que se cruza con AzureActivity para saber qué cambió.
2. vista-por-centro-coste: acumulada, agrupada por la etiqueta centro-coste, todo el perfil de facturación. Es la vista de Nuria.
3. vista-desarrollo-por-propietario: ámbito Contoso Airlines - Desarrollo, agrupada por la etiqueta propietario. Es la que hace que nadie deje una máquina encendida el viernes.

Las vistas se guardan, se comparten con el equipo y se anclan al panel del portal, igual que los libros de Azure Monitor del módulo 7. Y aquí llega el momento en que la disciplina de etiquetado pasa factura —en el buen sentido—: agrupar por etiqueta solo funciona si la etiqueta está. Un recurso sin centro-coste aparece en un cubo llamado «sin etiquetar», y ese cubo es exactamente el dinero que nadie reclama. En Contoso ese cubo era del 34 % del gasto antes de la política hereda-centro-coste; después de que la asignación con efecto Modify empezara a heredar la etiqueta del grupo de recursos, bajó al 3 %.

Dos advertencias sobre las etiquetas en el análisis de costes que se aprenden por las malas. La primera: las etiquetas no se aplican retroactivamente. Etiquetar hoy un recurso no reetiqueta el coste del mes pasado, así que el histórico anterior a la política sigue sin imputar. La segunda: no todos los tipos de recurso propagan la etiqueta a su registro de uso; algunos costes —tráfico, ciertos medidores de red— llegan al análisis sin etiqueta por naturaleza, y para esos hace falta el reparto del apartado 7.

Desde la línea de comandos, el ámbito y las consultas se manejan así:

--type admite ActualCost y AmortizedCost (apartado 4); --dataset-grouping acepta type="Dimension" para dimensiones como ServiceName, ResourceGroupName o ResourceLocation, y type="TagKey" para etiquetas. La combinación de estas dos consultas responde a las dos preguntas que siempre se hacen: «¿en qué gastamos?» y «¿de quién es?».

Ejecutada la primera consulta sobre el mes de julio, agrupada por recurso y ordenada de mayor a menor, el resultado (cifras orientativas y ficticias):

Las lecturas de esta tabla son la esencia de la lección:

• Cinco recursos concentran el 48 % de la factura. Es el patrón universal: el gasto se concentra. Optimizar por orden alfabético, o empezar por lo que más nos molesta, es perder el tiempo. Se empieza por arriba.
• La tercera partida más cara no es un servicio de negocio: es la observabilidad. log-contoso-pro cuesta más que la web de reservas entera. No significa que esté mal —significa que hay que dimensionarla conscientemente, con las tres palancas de 07-02—.
• La sexta partida no tiene recurso. La salida de datos sigue siendo invisible en cualquier vista agrupada por recurso; solo aparece agrupando por medidor.
• El 40 % de «resto» es donde vive el desperdicio silencioso: discos huérfanos, IP sin asociar, entornos olvidados. Nada de eso duele individualmente, y por eso nadie lo mira. Es el territorio de Azure Advisor y Resource Graph (08-04).

Un matiz que Nuria entendió inmediatamente y que conviene explicar siempre: las dos primeras partidas no son un problema. Son el precio de decisiones de arquitectura correctas y firmadas. El problema sería no saber que existen.

Cost Management ofrece dos métricas que dan cifras distintas para el mismo mes, y entender la diferencia evita discusiones estériles con finanzas:

El efecto es contraintuitivo hasta que se ve: con una reserva activa, el coste real de un VMSS puede ser 0 € durante meses, lo que sugiere que el recurso es gratis. No lo es; se pagó por adelantado. Si el reparto entre equipos se hiciera con coste real, el equipo que compró la reserva cargaría con todo y los demás disfrutarían de recursos aparentemente gratuitos.

Regla de Contoso: coste real para conciliar la factura del mes; coste amortizado para todo lo demás —análisis por recurso, reparto por centro-coste, cálculo del coste unitario y comparación entre meses—. Las vistas guardadas del apartado 2 usan amortizado, y está escrito en su descripción para que nadie se confunda.

Un presupuesto en Azure no bloquea nada. Es un umbral que dispara notificaciones y, opcionalmente, automatización. Conviene decirlo alto porque la expectativa contraria es habitual: «pusimos un presupuesto de 20.000 € y hemos gastado 23.000». Sí, porque un presupuesto avisa, no corta.

Los presupuestos de Contoso, derivados de la estimación con colchón de 08-01:

Tres decisiones de diseño detrás de esa tabla. La primera: existe un umbral sobre coste previsto, no solo real, porque avisar al 100 % de lo ya gastado llega tarde por definición; la previsión avisa a mitad de mes de que la tendencia no cabe. La segunda: los umbrales bajos (50-60 %) no son alarmas, son señales tempranas y van a correo, no a ag-guardia-contoso. La tercera: hay un presupuesto por etiqueta, que es la forma de presupuestar un proyecto que no tiene suscripción propia.

thresholdType acepta Actual y Forecasted, y contactGroups es lo que reutiliza ag-equipo-contoso, el grupo de acciones creado en 07-01: mismo canal de Teams, mismos destinatarios, misma disciplina de gravedades. No hay razón para inventar un canal nuevo para las alertas de coste; hay muchas razones para no hacerlo.

En producción, una alerta de presupuesto es información: alguien decide. En desarrollo, Contoso decidió que puede ser acción, porque el riesgo de equivocarse es asumible y el patrón —alguien deja algo encendido— es siempre el mismo.

El grupo de acciones invoca un runbook de aa-contoso-operaciones (07-04) que desasigna todo lo etiquetado con horario=laborable en rg-contoso-reservas-dev, y publica en Teams el desglose por propietario. Cuatro salvaguardas imprescindibles antes de dejar que algo así toque recursos:

• Ámbito acotado por etiqueta y por suscripción. El runbook filtra por entorno=desarrollo y aborta si encuentra cualquier recurso con entorno=produccion.
• Idempotencia y modo de simulación, exactamente como se construyó en 07-04.
• Aviso antes que acción: la primera vez que se supera se avisa; solo si se vuelve a superar en el mismo mes se actúa.
• Reversibilidad documentada: cómo se vuelve a encender, y quién puede hacerlo.

La alternativa con Logic Apps (logic-contoso-presupuesto) es igual de válida y a veces preferible: el flujo visual permite meter una aprobación humana en medio, con un botón en Teams, sin escribir código. La regla que Contoso escribió: automatización que apaga, solo en desarrollo; automatización que avisa, en todas partes.

Repartir el coste entre equipos tiene dos modalidades, y confundirlas genera peleas:

Contoso empezó por showback durante dos trimestres y pasó a chargeback después, que es el orden sensato: cargar a alguien un importe que no entiende es la mejor forma de que rechace todo el sistema.

El vehículo es la etiqueta centro-coste, con CC-1042 para el proyecto de reservas y CC-2077 para Contoso Millas. Con la política hereda-centro-coste aplicando efecto Modify desde la iniciativa «Base de gobernanza de Contoso», el 97 % del gasto queda imputado automáticamente.

Queda el 3 % y, sobre todo, queda el problema real: los costes compartidos. ¿De quién es fw-contoso-hub-pro? ¿Y log-contoso-pro? ¿Y fd-contoso-global? No son de nadie, o son de todos, que es lo mismo. Para eso existen las reglas de asignación de costes de Cost Management, que toman el gasto de un origen —una suscripción, un grupo de recursos o unas etiquetas— y lo reparten entre destinos con un criterio:

Las tres reglas de oro que Contoso adoptó tras la primera discusión: el criterio se acuerda antes de aplicarlo, se escribe, y se prefiere simple y aceptado a exacto y discutido. Un reparto proporcional al gasto es imperfecto pero comprensible; un modelo con quince coeficientes es más justo sobre el papel y nadie lo defiende en una reunión.

El análisis de costes del portal conserva un histórico limitado y no permite cruzar el coste con datos de negocio. Para eso existe la exportación programada: Cost Management deja cada día un fichero en una cuenta de almacenamiento.

El destino es stlagocontosopro, el Data Lake del módulo 3, y a partir de ahí el dato es un dato más: syn-contoso-analitica-pro lo consulta con SQL sin servidor sobre los ficheros del contenedor, se cruza con la tabla de reservas vendidas y sale el coste unitario que se trabajará en 08-05. Ojo con la ironía: consultar mal ese lago con Synapse sin servidor cuesta dinero, así que el propio análisis de costes tiene coste. Contoso particiona por fecha y lee solo el mes en curso.

Las columnas que más se usan del fichero exportado:

Otras dos vías de acceso al mismo dato. La API de Cost Management (Microsoft.CostManagement/query y /exports) permite integrarlo en herramientas propias, con la advertencia de que está limitada por peticiones y no está pensada para consultas interactivas masivas. Y el conector de Power BI para Cost Management, que es lo que Nuria usa: se conecta al perfil de facturación, trae el detalle de uso y permite construir el informe mensual sin depender de nadie. Cuando finanzas puede responder sus propias preguntas, ingeniería deja de ser un cuello de botella —y eso es, en sí mismo, media cultura FinOps—.

Cost Management incluye detección de anomalías basada en el patrón histórico de gasto de la suscripción. No es un umbral fijo: aprende la forma habitual del gasto y avisa de desviaciones significativas, con una explicación del servicio y el ámbito que la provocan. Es gratuita y se configura como una alerta de anomalía con destinatarios.

Es complementaria del presupuesto, no redundante:

Ese ejemplo es real dentro de la historia: nadie habría notado los 150 € diarios de más dentro de un presupuesto de 20.000 €, y sin embargo eran sqlpool-contoso encendido y olvidado tras un análisis puntual. Un presupuesto detecta el problema grande; una anomalía detecta el problema temprano. El flujo de trabajo cuando salta: mirar la vista diaria agrupada por servicio, identificar el día, cruzar con AzureActivity en log-contoso-pro para saber quién cambió qué, y actuar.

Antes o después, alguien compara el análisis de costes con el PDF de la factura y encuentra una diferencia. Las causas son conocidas y ninguna es un error:

• Periodo: la factura cubre el periodo de facturación, que no siempre coincide con el mes natural.
• Impuestos: el análisis de costes muestra importes sin IVA; la factura lo incluye. Es la diferencia más habitual y la más fácil de explicar.
• Créditos y descuentos: los créditos promocionales, los saldos de Enterprise y los descuentos negociados se aplican en la factura, no siempre en el análisis.
• Redondeo: se redondea por línea de uso, y hay decenas de miles de líneas.
• Compras del Marketplace de terceros: aparecen en la factura y se muestran aparte en el análisis.
• Reservas: el pago inicial aparece íntegro en coste real y repartido en amortizado (apartado 4).
• Retraso de datos: el uso tarda unas horas en consolidarse; los últimos días del mes se ajustan.

La regla: el análisis de costes sirve para decidir; la factura sirve para pagar. Pretender que cuadren al céntimo es una pérdida de tiempo. Lo que sí debe cuadrar es el orden de magnitud y la tendencia, y si no cuadran ahí, entonces sí hay algo que investigar.

El acceso al coste se rige por el RBAC del módulo 4, con la particularidad de que existen roles específicos de coste que no dan ningún acceso a los recursos:

Dos detalles que evitan sustos. El primero: en un Contrato de Cliente de Microsoft, el acceso a la factura se concede en la jerarquía de facturación, no en la de recursos —es decir, ser Propietario de la suscripción no da acceso al PDF de la factura—. El segundo: existe una opción a nivel de cuenta de facturación que oculta los precios a los usuarios de suscripción; si un compañero ve el uso pero no los importes, es casi seguro eso y no un problema de rol.

Asignar el rol al grupo de Microsoft Entra ID y en el grupo de administración, no persona a persona y suscripción a suscripción, es la misma buena práctica del módulo 4 aplicada aquí.

• Confundir la jerarquía de facturación con la de recursos. La sección de factura no es un grupo de administración, y un grupo de administración no aparece en la factura.
• Creer que un presupuesto bloquea el gasto. No lo hace. Avisa, y como mucho dispara automatización que tú construyes.
• Analizar el coste con ActualCost habiendo reservas. Verás recursos aparentemente gratuitos y repartos absurdos. Usa AmortizedCost para todo lo que no sea conciliar.
• Agrupar por etiqueta antes de tener etiquetado fiable. El cubo «sin etiquetar» te dirá la verdad sobre tu gobernanza, y no será agradable.
• Esperar que etiquetar hoy arregle el histórico. No es retroactivo.
• Pelearse con el céntimo de diferencia entre el análisis y la factura, en lugar de mirar impuestos, periodo y créditos.
• Repartir los costes compartidos sin acuerdo previo por escrito. Es la discusión más larga y menos productiva de FinOps.
• Consejo: crea hoy una vista diaria agrupada por servicio y ánclala al panel. Es la que te dirá cuándo cambió algo, que suele ser más útil que cuánto.
• Consejo: activa la detección de anomalías aunque tengas presupuesto. Detectan cosas distintas.
• Consejo: da Lector de Cost Management a mucha gente. El coste oculto no se optimiza, y nadie ha roto nada nunca por mirar una factura.

Ejercicio 1. Diseña el conjunto de presupuestos de Contoso Millas (centro-coste=CC-2077), que tiene 900 €/mes aprobados y comparte suscripción con otros proyectos. Indica ámbito, filtros, umbrales, tipo de umbral, destinatarios y qué automatización pondrías —y cuál no—.

Ejercicio 2. El análisis de costes muestra 17.800 € en julio y la factura dice 21.900 €. Enumera las causas posibles en orden de probabilidad y describe cómo comprobar cada una.

Ejercicio 3. Marta debe repartir entre CC-1042 y CC-2077 los costes compartidos de julio: fw-contoso-hub-pro (1.010 €), log-contoso-pro (1.640 €) y bastion-contoso-pro (205 €). Sabe que CC-1042 genera el 85 % del gasto directo y el 78 % de los GB ingeridos, y que ambos equipos usan el bastión ocasionalmente. Propón el reparto, justifica cada criterio y explica qué objeción esperas de cada equipo.

Solución 1: al compartir suscripción, el ámbito debe ser la suscripción con un filtro por la etiqueta centro-coste=CC-2077; no sirve un presupuesto de grupo de recursos si el proyecto tiene recursos en varios. Umbrales: 50 % real como señal temprana solo al responsable del proyecto; 80 % real al responsable y a Marta; 100 % previsto a Nuria, porque avisar de la tendencia a mitad de mes es lo único que permite reaccionar; y 110 % real como constancia de que se ha desbordado. Destinatarios por correo más contactGroups apuntando a ag-equipo-contoso, sin usar ag-guardia-contoso: un desvío de presupuesto nunca justifica despertar a nadie. Automatización: ninguna que apague nada, porque el proyecto tiene recursos de producción y el criterio de Contoso es que solo se automatiza el apagado en desarrollo; sí una Logic App que publique en Teams el desglose por propietario y abra una incidencia. Requisito previo indispensable: verificar que la política hereda-centro-coste cubre los grupos de recursos del proyecto, porque un presupuesto filtrado por etiqueta solo ve lo etiquetado y un recurso sin etiqueta gastaría fuera del radar.

Solución 2: por orden de probabilidad. (1) IVA: 17.800 × 1,21 = 21.538 €, muy cerca de la diferencia; el análisis de costes muestra importes sin impuestos y es casi con seguridad la causa principal. Se comprueba mirando la línea de impuestos del PDF. (2) Periodo de facturación distinto del mes natural: se comprueba en la cabecera de la factura y se repite el análisis con un intervalo personalizado que coincida. (3) Compras del Marketplace de terceros —una imagen de firewall virtual, una licencia—, que aparecen en la factura y se listan aparte en el análisis. (4) Ámbito equivocado: el análisis se hizo sobre una suscripción y la factura cubre el perfil de facturación completo, que incluye también Contoso Airlines - Desarrollo; se comprueba cambiando el ámbito al perfil de facturación. (5) Retraso de consolidación si el análisis se ejecutó antes de cerrar el mes. (6) Créditos aplicados en un sentido u otro. El método: reproducir el análisis con ámbito «perfil de facturación», intervalo igual al periodo de la factura, tipo ActualCost y sin filtros, y comparar entonces; el resto de la diferencia serán impuestos.

Solución 3: log-contoso-pro se reparte proporcionalmente a los GB ingeridos (78 %/22 %): 1.279 € a CC-1042 y 361 € a CC-2077. Es el criterio más defendible porque la magnitud repartida es exactamente la que se factura, y es medible con la tabla Usage agrupada por _ResourceId (07-02); si un equipo lo discute, se le enseña la consulta. fw-contoso-hub-pro se reparte proporcionalmente al gasto directo (85 %/15 %): 859 € y 152 €. No es exacto —el firewall procesa gigabytes, no euros— pero medir el tráfico por origen exigiría registros de flujo y su propia ingesta, que costaría más que la precisión que aporta; se documenta como aproximación aceptada. bastion-contoso-pro se reparte a partes iguales: 102,50 € cada uno, porque el uso es ocasional, no medible sin esfuerzo y de importe pequeño; discutirlo cuesta más que pagarlo. Objeciones esperables: CC-2077 alegará que el firewall estaba desplegado antes de que Millas existiera y que su tráfico es marginal —respuesta: el criterio es proporcional al gasto, se revisa cada semestre, y si aporta una medición mejor se cambia—; CC-1042 alegará que paga el 85 % de una infraestructura que habilita a otros —respuesta: es la contrapartida de que el coste unitario baja para todos al compartirla—. Y la regla de fondo: el reparto se acuerda antes del cierre del mes y se publica en la revisión mensual (08-05), nunca se comunica por primera vez junto con el importe.

Ya distingues las dos jerarquías —cuenta de facturación, perfil, sección de factura y suscripción, frente a grupo de administración, suscripción, grupo de recursos y recurso— y sabes que solo se tocan en la suscripción, lo que explica media docena de preguntas que aparecen siempre. Manejas el análisis de costes con sus controles reales: ámbito, intervalo, granularidad diaria o acumulada, agrupación por servicio, ubicación, grupo de recursos, medidor y etiqueta, filtros, previsión y vistas guardadas, con las tres vistas de Contoso como plantilla. Y has comprobado el valor exacto del etiquetado: el cubo «sin etiquetar» pasó del 34 % al 3 % gracias a la política hereda-centro-coste del módulo 4, con las dos advertencias de que las etiquetas no son retroactivas y de que ciertos medidores nunca las llevan.

Tienes el desglose real de la factura de Contoso: 17.800 € en julio, con cinco recursos concentrando el 48 % —sql-contoso-reservas-pro con su réplica, aks-contoso-operaciones, log-contoso-pro, vmss-api-disponibilidad-pro y fw-contoso-hub-pro—, la salida de datos como sexta partida sin recurso al que mirar, y un 40 % de cola larga donde vive el desperdicio silencioso. Sabes que el gasto se concentra y que por eso se optimiza de arriba abajo, y que las partidas más caras no son necesariamente problemas: son decisiones de arquitectura con precio visible. Distingues coste real de coste amortizado y por qué con reservas el real miente sobre lo que cuesta cada recurso.

En el plano operativo llevas los presupuestos de Contoso con sus umbrales sobre coste real y previsto, reutilizando ag-equipo-contoso, la automatización de la respuesta en desarrollo con el runbook Detener-IniciarEntornosDev y sus cuatro salvaguardas, y la regla que las gobierna: automatización que apaga solo en desarrollo, automatización que avisa en todas partes. Sabes repartir con showback antes que chargeback, con centro-coste como vehículo y reglas de asignación para lo compartido, prefiriendo un criterio simple y acordado a uno exacto y discutido. Y sabes sacar el dato fuera —exportaciones diarias a stlagocontosopro, API y Power BI—, activar la detección de anomalías que encontró sqlpool-contoso encendido, explicar por qué la factura no cuadra al céntimo, y repartir los permisos de coste sin dar acceso a los recursos.

Con la factura medida y repartida, la conversación cambia de pregunta. Ya no es «¿cuánto gastamos?», sino «¿cuánto de esto podríamos no gastar sin cambiar nada de lo que hacemos?». Y la primera respuesta, la más grande y la más inmediata, no exige tocar una sola línea de arquitectura: basta con comprometerse. db-reservas, los nodos de aks-contoso-operaciones, los planes Premium v3 y la línea base del VMSS llevan meses funcionando a tarifa de pago por uso, que es la más flexible y la más cara que existe. La lección siguiente trata de las reservas, los planes de ahorro, las instancias de acceso puntual y Azure Hybrid Benefit: qué son, en qué se diferencian, cuánto descuentan, qué se compromete Contoso a comprar y qué deja deliberadamente a demanda —y por qué reservar antes de estabilizar la arquitectura es la forma más cara que existe de ahorrar dinero—.