El problema
La factura de Azure dice cuánto, no qué hacer. En un mes normal tres VMs de SQL Server en E16s_v5 llegan como mucho al 15% de CPU y usan un tercio de su memoria, porque se dimensionaron para una migración hace dos años; una VM de informes se apagó desde dentro de Windows hace tres semanas y se sigue pagando como si estuviera encendida, porque nadie la desasignó; catorce VMs de desarrollo y pruebas funcionan todas las noches y todos los fines de semana; los discos y las IP públicas de un proyecto de migración que terminó en agosto siguen ahí, sin conectar y sin etiquetar; una reserva para diez servidores de batch va al 55% desde que la mitad del batch se fue a otra plataforma, caduca en seis semanas y está configurada para renovarse sola; cuarenta VMs de producción funcionan todo el mes con pago por uso mientras solo una cuarta parte del gasto en VMs está cubierta por un compromiso; el 11% de la factura no tiene centro de coste, así que nadie pregunta por él; un centro de coste cierra el mes un 14% por encima del presupuesto y va camino de repetirlo; y el coste por usuario activo de los canales digitales sube un 15% porque los usuarios han bajado y el coste no. No es el panel de costes que publiqué al principio de la serie, que busca la semana que se tuerce en AWS y Azure mientras pasa: es la revisión mensual que viene después, y decide qué redimensionar, borrar, programar y comprometer, y quién paga cada línea.
Qué he hecho
- Redimensionado: VMs cuyo p95 de CPU y pico de memoria en 30 días caben en un tamaño menos dentro de la misma familia, con el uso previsto después del cambio y el ahorro mensual, y VMs ociosas; las VMs cubiertas por una reserva se marcan, porque redimensionarlas no ahorra nada hasta que la capacidad liberada se usa o se cambia.
- Desperdicio: VMs paradas pero no desasignadas, VMs que no son de producción encendidas día y noche sin etiqueta de horario, discos administrados sin conectar desde hace semanas e IP públicas que no están asociadas a nada.
- Compromisos: reservas y planes de ahorro por debajo de su objetivo de uso con el coste sin usar del mes, los que caducan en los próximos 90 días con la decisión de renovar o cambiar (crítico cuando se renovarían solos con un uso bajo), y la cobertura de las VMs con las VMs estables en pago por uso que cubriría un compromiso.
- Showback: el mes por centro de coste frente a su presupuesto, la previsión del mes en curso, el coste sin etiqueta de centro de coste y dónde está, el coste unitario de cada centro de coste y las VMs a las que les faltan las etiquetas que necesita el showback.
report.htmlcon un veredicto del mes,savings-pack.mdpara la revisión mensual de FinOps con una columna de decisión para cada redimensionado y cada compromiso, CSV de redimensionado, desperdicio, compromisos, showback y acciones, y un exportador de solo lectura en PowerShell para los módulos Az y las API de reservas y planes de ahorro.
Cómo está hecho
Python solo con la librería estándar. La parte de costes es la exportación FOCUS tal como la escribe Cost Management: el coste efectivo para el gasto amortizado, el coste facturado al lado, el ahorro de los compromisos como coste de lista menos coste efectivo de las filas que cubren, y la parte sin usar a partir de las filas marcadas como no usadas. Cada ahorro es una estimación mensual al ritmo de los últimos siete días, y el pack explica cómo se ha calculado: la mitad de vCPU en la misma familia es la mitad del coste de cómputo, un horario de oficina son 60 de 168 horas, y un compromiso es una estimación por arriba que hay que contrastar con Azure Advisor antes de comprar. La cobertura se mide en horas, porque una VM de Windows o de SQL Server cubierta por una reserva sigue teniendo filas de pago por uso por su licencia. La demo es un grupo asegurador inventado con cinco suscripciones y 133 VMs, revisado el 4 de noviembre sobre octubre con precios redondos inventados y los problemas puestos a propósito: identifica 11.101 euros al mes de ahorro sobre un mes de 94.403 euros. 15 tests, un runbook para el ciclo mensual y la revisión de FinOps, y un workflow de GitHub Actions que ejecuta los tests y regenera los datos de la demo y la captura.
Qué aprendí
De trabajar con Azure Cost Management y aplicar el FinOps Framework, con reservas, planes de ahorro y compromisos; de optimizar costes de Azure con redimensionado y reservas; de implantar showback y chargeback y métricas de coste unitario; de la gestión de activos de software y el control del coste de licencias y SaaS, con Apptio y Flexera, TBM, FOCUS y GreenOps; de los casos de negocio con ROI y beneficios medibles y de ser responsable de un presupuesto de IT; y de operar un entorno híbrido de AWS y Azure con Azure Monitor y Log Analytics. Las lecciones que hay detrás de la herramienta son que un redimensionado lo decide el pico, no la media; que una VM parada no es una VM desasignada; que un disco sin conectar se paga entero y nadie lo echa de menos; que el desperdicio hay que arreglarlo antes de comprar un compromiso, o la reserva congela durante años el sobredimensionado de hoy; que un compromiso por debajo del 80% es dinero pagado por nada, y uno que se renueva solo al 55% es el mismo error otra vez; que el coste sin etiquetar no tiene dueño, así que nadie pregunta nunca por él; y que el coste unitario es el número que lee el negocio.
Siguientes pasos
- Ejecutar las exportaciones y la revisión el cuarto día de cada mes y enviar a cada responsable sus líneas.
- Dimensionar los compromisos con las recomendaciones de Cost Management y poner precio a los redimensionados con la API de precios de Azure.
- Añadir los servicios PaaS que se redimensionan igual, como los planes de App Service y Azure SQL Database.
¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.
The problem
The Azure bill tells you how much, not what to do. In a typical month three SQL Server VMs on E16s_v5 peak at 15% CPU and use a third of their memory, because they were sized for a migration two years ago; a reporting VM was shut down from inside Windows three weeks ago and is still billed as if it were running, because nobody deallocated it; fourteen development and test VMs run every night and every weekend; the disks and public IPs of a migration project that finished in August are still there, unattached and untagged; a reservation for ten batch servers runs at 55% since half the batch moved elsewhere, expires in six weeks and is set to renew itself; forty production VMs run all month on pay-as-you-go while only a quarter of the VM spend is covered by a commitment; 11% of the bill has no cost centre, so nobody is asked about it; one cost centre ends the month 14% over budget and is on course to do it again; and the cost per active user of the digital channels goes up 15% because the users fell and the cost did not. This is not the cost dashboard I published at the start of the series, which looks for the week that goes wrong across AWS and Azure while it happens: it is the monthly review that comes after, and decides what to resize, delete, schedule and commit, and who pays for each line.
What I built
- Right-sizing: VMs whose CPU p95 and peak memory over 30 days fit in one size down within the same family, with the projected use after the resize and the monthly saving, and idle VMs; VMs covered by a reservation are flagged, because resizing them saves nothing until the freed capacity is used or exchanged.
- Waste: VMs stopped but not deallocated, non-production VMs on around the clock with no schedule tag, managed disks unattached for weeks and public IPs associated with nothing.
- Commitments: reservations and savings plans under their utilisation target with the unused cost of the month, the ones expiring in the next 90 days with the renew or exchange decision (critical when they would renew themselves at a low utilisation), and the VM coverage with the steady pay-as-you-go VMs a commitment would cover.
- Showback: the month by cost centre against its budget, the forecast for the current month, the cost with no cost centre tag and where it sits, the unit cost per cost centre and the VMs missing the tags showback needs.
report.htmlwith a verdict for the month,savings-pack.mdfor the monthly FinOps review with a decision column for every resize and commitment, CSVs for right-sizing, waste, commitments, showback and actions, and a read-only PowerShell exporter for the Az modules and the reservations and savings plans APIs.
How it is built
Python with the standard library only. The cost side is the FOCUS export as Cost Management writes it: effective cost for the amortised spend, billed cost next to it, the savings of the commitments as list minus effective cost of the rows they cover, and the unused part from the rows marked as unused. Every saving is an estimate per month at the run rate of the last seven days, and the pack says how it was worked out: half the vCPUs in the same family is half the compute cost, an office-hours schedule is 60 of 168 hours, and a commitment is an upper estimate to be checked against Azure Advisor before buying. Coverage is measured in hours, because a Windows or SQL Server VM covered by a reservation still has pay-as-you-go rows for its licence. The demo is a made-up insurance group with five subscriptions and 133 VMs, reviewed on 4 November for October with round fictional prices and the problems placed on purpose: it identifies 11,101 euros a month of savings on a 94,403 euro month. 15 tests, a runbook for the monthly cycle and the FinOps review, and a GitHub Actions workflow that runs the tests and rebuilds the demo data and the screenshot.
What I learned
From working with Azure Cost Management and applying the FinOps Framework, with reservations, savings plans and commitments; from optimising Azure costs with right-sizing and reservations; from implementing showback and chargeback and unit cost metrics; from software asset management and licence and SaaS cost control, with Apptio and Flexera, TBM, FOCUS and GreenOps; from business cases with ROI and measurable benefits and from owning an IT budget; and from operating a hybrid AWS and Azure environment with Azure Monitor and Log Analytics. The lessons behind the tool are that the peak decides a resize, not the average; that a stopped VM is not a deallocated one; that an unattached disk is billed in full and nobody misses it; that the waste has to be fixed before buying a commitment, or the reservation locks in today's oversizing for years; that a commitment under 80% is money paid for nothing, and one that renews itself at 55% is the same mistake again; that untagged cost has no owner, so nobody is ever asked about it; and that the unit cost is the number the business reads.
Next steps
- Run the exports and the review on the fourth day of every month and send each owner their lines.
- Size the commitments from the Cost Management benefit recommendations and price the resizes from the Azure Retail Prices API.
- Add the PaaS services that right-size the same way, such as App Service plans and Azure SQL Database.
Want to bring it to your environment or adapt it to your case? Get in touch and we can look at it together.
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 →