Qué vas a conseguir
Una nube en la que cada euro tiene dueño: presupuestos que avisan antes de que el gasto se pase, cada recurso etiquetado con su centro de coste, un informe mensual por equipo que se puede enseñar (showback) o facturar (chargeback), compromisos de uso comprados con datos y no con intuición, y los datos de coste exportados en un formato abierto para cruzarlos con lo demás. Y el método para la reunión que nadie quiere: "la factura de Azure ha subido un 40 % este mes, ¿qué ha pasado?".
Antes de empezar
- Saber qué contrato tiene la organización con Microsoft: Enterprise Agreement (EA), Microsoft Customer Agreement (MCA) o a través de un partner (CSP). Cambia los ámbitos de facturación y quién puede ver qué.
- Rol de Cost Management Reader (o Contributor para crear presupuestos y exportaciones) en las suscripciones, y un rol de facturación si vas a ver el contrato entero.
- Una cuenta de almacenamiento para las exportaciones, en una suscripción de plataforma.
- La lista de centros de coste y de responsables de cada aplicación, que te dará Finanzas. Sin ella, las etiquetas son nombres inventados.
1. Ámbitos: dónde se mira cada coste
Cost Management muestra los costes del ámbito que eliges arriba a la izquierda:
- Ámbitos de facturación: la cuenta de facturación y, según el contrato, departamentos y cuentas de inscripción (EA) o perfiles de facturación y secciones de factura (MCA). Es donde se ven las compras: reservas, planes de ahorro, Marketplace.
- Ámbitos de Azure RBAC: grupos de administración, suscripciones y grupos de recursos. Es donde trabaja cada equipo, y donde se dan permisos con roles normales de Azure.
Un diseño que funciona: un grupo de administración por área (Plataforma, Aplicaciones de negocio, Datos), las suscripciones de producción y no producción separadas, y Finanzas con lectura en el ámbito de facturación. Cada responsable ve su suscripción y nada más.
2. Presupuestos y alertas
Un presupuesto no para nada: avisa. Se crea en el ámbito que quieras vigilar con un importe, un periodo (mensual, trimestral o anual) y umbrales sobre el coste real o el previsto.
- La alerta sobre el previsto es la útil: avisa el día 10 de que, a este ritmo, el mes acabará en 20.000 €, cuando todavía se puede hacer algo.
- Además de los presupuestos, crea una alerta de anomalías en cada suscripción importante (Cost alerts › Anomaly alert): avisa de un cambio brusco en el gasto diario sin que tengas que fijar un importe.
- Un action group puede lanzar un runbook o una aplicación lógica que, en un entorno de pruebas, apague máquinas al llegar al 100 %. En producción, no: ahí solo se avisa.
3. Etiquetas: showback y chargeback
Sin etiquetas, el coste se reparte por suscripción y grupo de recursos y no hay más. Con ellas, por lo que quiera Finanzas. Un juego mínimo:
| Etiqueta | Ejemplo | Para qué |
|---|---|---|
CentroCoste | CC-4120 | El chargeback: a qué presupuesto va |
Aplicacion | crm-ventas | Agrupar todo lo de una aplicación aunque esté en varios grupos de recursos |
Entorno | prod, pre, dev | Separar lo que se puede apagar de noche |
Responsable | equipo-crm | A quién se le pregunta |
Para que existan de verdad:
- Azure Policy: Require a tag on resource groups en los grupos de recursos, e Inherit a tag from the resource group if missing para que los recursos la hereden.
- Herencia de etiquetas en Cost Management (Settings › Tag inheritance, en EA y MCA): aplica las etiquetas de la suscripción y del grupo de recursos a los registros de coste, incluso de recursos que no admiten etiquetas.
- Reglas de asignación de costes para lo compartido (la red central, el firewall, Log Analytics de plataforma): se reparte entre los centros de coste por un porcentaje o en proporción a su gasto.
az graph query -q "Resources | where isnull(tags['CentroCoste']) | summarize total=count() by resourceGroup, subscriptionId | order by total desc" --first 20Showback es enseñar a cada área lo que gasta; chargeback, cargárselo en su presupuesto. Se empieza siempre por el primero, unos meses, hasta que las cifras se aceptan. Facturar con un 30 % de coste sin etiquetar solo genera discusiones.
4. Análisis de costes
En Cost analysis, las vistas que más se usan:
- Daily costs agrupado por Service name: un pico se ve como una columna que destaca.
- Cost by resource: los recursos más caros del ámbito, con su tipo y grupo de recursos.
- Group by › Tag › CentroCoste: el informe de showback en un clic, que se guarda como vista y se programa por correo.
- Actual cost frente a Amortized cost: en el real, una reserva anual pagada por adelantado aparece entera el mes de la compra; en el amortizado, repartida por días entre los recursos que la usan. Para showback, siempre amortizado.
5. Ajustar tamaño con Advisor
Advisor › Cost propone apagar o reducir máquinas virtuales infrautilizadas, quitar discos e IP públicas sin asociar, y comprar reservas. En la configuración de Advisor se ajusta el umbral de CPU y el periodo que mira para las recomendaciones de máquinas virtuales.
- Antes de reducir una máquina, mira la memoria y los picos, no solo la media de CPU: un servidor de informes que trabaja el día 1 de cada mes parece ocioso los otros 29.
- Los discos sin asociar y las instantáneas antiguas son el ahorro sin riesgo: se revisan cada mes.
- Los entornos de desarrollo con apagado automático fuera de horario ahorran más que cualquier reserva.
6. Reservas o plan de ahorro
| Reserva | Plan de ahorro para proceso | |
|---|---|---|
| Compromiso | Un tipo de recurso concreto (familia de VM, región) durante 1 o 3 años | Un importe por hora en proceso durante 1 o 3 años |
| Flexibilidad | Dentro de la familia y región (flexibilidad de tamaño); se puede cambiar o devolver con límites | Cualquier familia, región y servicios de proceso compatibles |
| Descuento | El mayor | Algo menor |
| Cuándo | Cargas estables que no van a cambiar: controladores de dominio, bases de datos, la VDI de la oficina | Cargas que cambian de tamaño o de región, o una mezcla de servicios |
- Primero se ajusta el tamaño, después se compra: reservar una máquina que sobra la deja sobrando tres años.
- Se aplica primero la reserva y después el plan de ahorro; muchas organizaciones combinan reservas para la base fija y un plan de ahorro para el resto.
- El ámbito de la reserva (compartido, una suscripción, un grupo de recursos o un grupo de administración) decide quién se beneficia. Compartido aprovecha mejor la compra; para chargeback, el coste amortizado la reparte entre quien la usa.
- Se mira la utilización de cada reserva cada mes en Reservations: una reserva al 40 % es dinero que se paga por nada.
7. Exportar en FOCUS
FOCUS (FinOps Open Cost and Usage Specification) es un esquema abierto de datos de coste: las mismas columnas para Azure, AWS u otros, con el coste facturado y el efectivo (amortizado) en el mismo fichero.
Columnas como BilledCost, EffectiveCost, ServiceName, ResourceName, RegionName, SubAccountName y Tags dejan hacer el showback en Power BI o en Fabric sin traducir el formato de cada proveedor. La exportación FOCUS no admite el ámbito de grupo de administración: en EA se hace en la cuenta de facturación o en cada suscripción.
8. El ticket: "la factura ha subido un 40 % este mes"
Se busca en este orden, de lo más fácil de confirmar a lo más difícil:
- ¿Es una compra? Cambia la vista a Actual cost y filtra por Charge type = Purchase. Una reserva de tres años o una licencia de Marketplace aparece entera en un mes. Si es eso, en amortizado no hay subida y la conversación termina.
- ¿Qué servicio ha subido? Daily costs agrupado por servicio, este mes frente al anterior. Los sospechosos habituales: Log Analytics (alguien activó registros de diagnóstico detallados), Bandwidth (salida de datos a internet o entre regiones), Virtual Machines (una máquina nueva o más grande), Microsoft Defender for Cloud (un plan activado en todas las suscripciones), Backup y Storage (instantáneas que nadie borra).
- ¿Qué recurso, y desde qué día? Filtra por ese servicio y agrupa por recurso: la columna del día en que empezó señala el cambio.
- ¿Quién y por qué? El registro de actividad del recurso dice quién lo creó o lo cambió de tamaño ese día. Con eso se habla con el responsable, no con toda la empresa.
az rest --method post --url "https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.CostManagement/query?api-version=2023-03-01" --body @consulta.json --query "properties.rows" -o table# consulta.json:# {"type":"AmortizedCost","timeframe":"Custom","timePeriod":{"from":"2026-09-01","to":"2026-09-30"},# "dataset":{"granularity":"None","aggregation":{"total":{"name":"Cost","function":"Sum"}},# "grouping":[{"type":"Dimension","name":"ServiceName"}]}}az monitor activity-log list --resource-group rg-crm-prod --start-time 2026-09-12 --query "[?contains(operationName.value,'write')].{quien:caller,que:operationName.value,cuando:eventTimestamp}" -o tableLa respuesta que se lleva a la reunión: cuánto subió, por qué (una frase), quién lo decidió, si es puntual o se queda, y qué se hace (borrarlo, reducir la retención de registros, mover la salida de datos, reservar si es permanente). Y una alerta de anomalía o un presupuesto nuevo para que el siguiente se vea en dos días y no a fin de mes.
No borres un recurso caro solo porque nadie responde en una hora. Etiquétalo, avisa al responsable de la suscripción y apágalo (no lo borres) si el coste lo justifica: una máquina detenida y desasignada deja de costar en proceso; los discos se siguen pagando.
Siguientes pasos
- Azure Monitor y Log Analytics: la retención y las tablas que más ingieren son, muchas veces, la primera línea de la factura que nadie mira.
- Terraform: las etiquetas se ponen en el código y las revisa el pipeline antes de crear nada; es más barato que perseguirlas después.
- Juntar Azure y AWS en un solo informe por centro de coste es lo que permite FOCUS. Es la idea del repositorio 01-finops-cloud-cost-dashboard de mi GitHub.
¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.
What you'll get
A cloud where every euro has an owner: budgets that warn before spending overshoots, every resource tagged with its cost centre, a monthly report per team that can be shown (showback) or charged (chargeback), usage commitments bought on data rather than gut feeling, and cost data exported in an open format to combine with everything else. And the method for the meeting nobody wants: "the Azure bill went up 40% this month, what happened?".
Before you start
- Know which agreement the organisation has with Microsoft: Enterprise Agreement (EA), Microsoft Customer Agreement (MCA) or through a partner (CSP). It changes the billing scopes and who can see what.
- The Cost Management Reader role (or Contributor to create budgets and exports) on the subscriptions, and a billing role if you are going to see the whole agreement.
- A storage account for exports, in a platform subscription.
- The list of cost centres and of owners of each application, which Finance will give you. Without it, tags are made-up names.
1. Scopes: where each cost is viewed
Cost Management shows the costs of the scope you pick at the top left:
- Billing scopes: the billing account and, depending on the agreement, departments and enrollment accounts (EA) or billing profiles and invoice sections (MCA). This is where purchases show up: reservations, savings plans, Marketplace.
- Azure RBAC scopes: management groups, subscriptions and resource groups. This is where each team works, and where permissions are granted with normal Azure roles.
A design that works: one management group per area (Platform, Business applications, Data), production and non-production subscriptions kept apart, and Finance with read access at the billing scope. Each owner sees their subscription and nothing else.
2. Budgets and alerts
A budget doesn't stop anything: it warns. It is created at the scope you want to watch with an amount, a period (monthly, quarterly or yearly) and thresholds on actual or forecasted cost.
- The forecasted alert is the useful one: on the 10th it warns that, at this pace, the month will end at €20,000, while there is still time to act.
- Besides budgets, create an anomaly alert on each important subscription (Cost alerts › Anomaly alert): it warns of a sharp change in daily spend without you having to set an amount.
- An action group can trigger a runbook or a logic app that, in a test environment, shuts machines down at 100%. In production, no: there it only warns.
3. Tags: showback and chargeback
Without tags, cost is split by subscription and resource group and that's it. With them, by whatever Finance wants. A minimum set:
| Tag | Example | What for |
|---|---|---|
CostCentre | CC-4120 | Chargeback: which budget it goes to |
Application | crm-sales | Grouping everything for an application even across several resource groups |
Environment | prod, pre, dev | Separating what can be switched off at night |
Owner | crm-team | Who to ask |
To make them real:
- Azure Policy: Require a tag on resource groups on resource groups, and Inherit a tag from the resource group if missing so resources inherit it.
- Tag inheritance in Cost Management (Settings › Tag inheritance, on EA and MCA): applies subscription and resource group tags to cost records, even for resources that don't support tags.
- Cost allocation rules for shared items (the central network, the firewall, the platform Log Analytics): split between cost centres by a percentage or in proportion to their spend.
az graph query -q "Resources | where isnull(tags['CostCentre']) | summarize total=count() by resourceGroup, subscriptionId | order by total desc" --first 20Showback is showing each area what it spends; chargeback, charging it to their budget. You always start with the first one, for a few months, until the figures are accepted. Charging with 30% of cost untagged only creates arguments.
4. Cost analysis
In Cost analysis, the most used views:
- Daily costs grouped by Service name: a spike shows up as a column that stands out.
- Cost by resource: the most expensive resources in the scope, with their type and resource group.
- Group by › Tag › CostCentre: the showback report in one click, saved as a view and scheduled by email.
- Actual cost versus Amortized cost: in actual, a yearly reservation paid upfront shows in full in the month of purchase; in amortized, spread by day across the resources that use it. For showback, always amortized.
5. Right-sizing with Advisor
Advisor › Cost suggests shutting down or resizing underused virtual machines, removing unattached disks and public IPs, and buying reservations. In Advisor's configuration you set the CPU threshold and the lookback period for virtual machine recommendations.
- Before downsizing a machine, look at memory and peaks, not just average CPU: a reporting server that works on the 1st of every month looks idle the other 29 days.
- Unattached disks and old snapshots are risk-free savings: they get reviewed every month.
- Development environments with auto-shutdown out of hours save more than any reservation.
6. Reservations or a savings plan
| Reservation | Savings plan for compute | |
|---|---|---|
| Commitment | A specific resource type (VM family, region) for 1 or 3 years | An hourly amount of compute for 1 or 3 years |
| Flexibility | Within the family and region (instance size flexibility); can be exchanged or refunded within limits | Any family, region and eligible compute services |
| Discount | The highest | Somewhat lower |
| When | Stable workloads that won't change: domain controllers, databases, the office VDI | Workloads that change size or region, or a mix of services |
- Right-size first, then buy: reserving a machine that is oversized keeps it oversized for three years.
- The reservation is applied first and then the savings plan; many organisations combine reservations for the fixed baseline and a savings plan for the rest.
- The reservation's scope (shared, one subscription, one resource group or a management group) decides who benefits. Shared gets the most out of the purchase; for chargeback, amortized cost spreads it across whoever uses it.
- Check each reservation's utilisation every month in Reservations: a reservation at 40% is money paid for nothing.
7. Exporting in FOCUS
FOCUS (FinOps Open Cost and Usage Specification) is an open cost data schema: the same columns for Azure, AWS and others, with billed cost and effective (amortized) cost in the same file.
Columns such as BilledCost, EffectiveCost, ServiceName, ResourceName, RegionName, SubAccountName and Tags let you build showback in Power BI or Fabric without translating each provider's format. The FOCUS export doesn't support the management group scope: on EA it is done at the billing account or on each subscription.
8. The ticket: "the bill went up 40% this month"
Search in this order, from easiest to confirm to hardest:
- Is it a purchase? Switch the view to Actual cost and filter by Charge type = Purchase. A three-year reservation or a Marketplace licence shows in full in one month. If that's it, amortized shows no increase and the conversation is over.
- Which service went up? Daily costs grouped by service, this month against last. The usual suspects: Log Analytics (someone enabled verbose diagnostic logs), Bandwidth (data egress to the internet or between regions), Virtual Machines (a new or bigger machine), Microsoft Defender for Cloud (a plan enabled on every subscription), Backup and Storage (snapshots nobody deletes).
- Which resource, and since which day? Filter by that service and group by resource: the column for the day it started points at the change.
- Who and why? The resource's activity log says who created or resized it that day. With that you talk to the owner, not the whole company.
az rest --method post --url "https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.CostManagement/query?api-version=2023-03-01" --body @query.json --query "properties.rows" -o table# query.json:# {"type":"AmortizedCost","timeframe":"Custom","timePeriod":{"from":"2026-09-01","to":"2026-09-30"},# "dataset":{"granularity":"None","aggregation":{"total":{"name":"Cost","function":"Sum"}},# "grouping":[{"type":"Dimension","name":"ServiceName"}]}}az monitor activity-log list --resource-group rg-crm-prod --start-time 2026-09-12 --query "[?contains(operationName.value,'write')].{who:caller,what:operationName.value,when:eventTimestamp}" -o tableThe answer you take to the meeting: how much it went up, why (one sentence), who decided it, whether it is one-off or here to stay, and what happens next (delete it, cut log retention, move the egress, reserve if it is permanent). And an anomaly alert or a new budget so the next one is seen in two days and not at month end.
Don't delete an expensive resource just because nobody answers within an hour. Tag it, warn the subscription owner and stop it (don't delete it) if the cost justifies it: a stopped and deallocated machine stops costing compute; its disks are still charged.
Next steps
- Azure Monitor and Log Analytics: retention and the tables that ingest the most are often the first line of the bill nobody looks at.
- Terraform: tags go in the code and the pipeline checks them before anything is created; it is cheaper than chasing them afterwards.
- Bringing Azure and AWS together in a single report per cost centre is what FOCUS makes possible. That is the idea behind the 01-finops-cloud-cost-dashboard repository on my GitHub.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →