Una reserva al 55% que se renueva sola y VMs paradas que se pagan: la revisión de costes de Azure

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.html con un veredicto del mes, savings-pack.md para 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.