Cinco rubros que inflan la factura de Azure

La mayoría de las facturas de Azure en empresas medianas no crecen porque alguien tomó una mala decisión. Crecen porque decisiones locales razonables se acumulan en un número mensual que nadie tiene asignado. Un SKU más grande para pasar el cierre de trimestre. Un disco que se quedó "por si acaso" después de una migración. Un workspace de logs creado por un equipo que ya no está.

Ese es el patrón que vale la pena buscar. No desperdicio en sentido moral, sino costo sin dueño.

Abajo están los cinco rubros que vemos con más frecuencia en una revisión de solo lectura, ordenados por cuántas veces explican la diferencia entre "subió la factura" y "entregamos más". Los cinco son visibles en el portal, y cuatro los puedes revisar tú mismo esta semana.

1. Discos y snapshots que sobrevivieron a su máquina virtual

Borrar una VM no borra sus discos. El disco del sistema y los discos de datos quedan sin adjuntar, y el almacenamiento Premium SSD se factura sobre el tamaño aprovisionado, no sobre los datos que contiene. Un ambiente de tres VM dado de baja puede dejar cientos de gigabytes de almacenamiento Premium aprovisionado que nadie mira, porque aparece en la vista de almacenamiento y no en la de cómputo.

Los snapshots agravan el problema. Sin política de retención, las cadenas de hace dos años conviven con las de este mes. Su naturaleza incremental hace que cada una parezca pequeña, y el total no lo es.

Cómo se produce el cargo: comportamiento por defecto de la plataforma, ausencia de política de retención, y una migración declarada terminada antes que la limpieza.

Qué revisar: discos administrados sin adjuntar, y un inventario de snapshots agrupado por fecha de creación.

2. SKUs dimensionados para el pico y facturados por el mes completo

Una VM elegida para sobrevivir el proceso batch de cierre de mes corre todas las horas del mes, haya batch o no. La facturación sigue al SKU, no a la utilización. Si la carga se queda en 15% de la capacidad aprovisionada durante 690 de esas 720 horas, la factura se calcula igual sobre 100%.

Aquí es donde las conversaciones de right-sizing suelen fallar. La respuesta rara vez es "bajemos todo un tamaño". Es una mezcla: series burstable para cargas que de verdad están ociosas, capacidad reservada para las que corren constante, y autoscaling para la capa que solo importa en los picos. Cada instrumento tiene un perfil de riesgo distinto. Elegir entre ellos requiere la utilización por percentil, no el promedio.

Qué revisar: CPU y memoria P95 por VM en 30 días, al lado del SKU que estás pagando.

3. Red que nunca estuvo en el presupuesto

Cómputo es la parte que todo el mundo modela. La red es la parte que aparece después.

• Salida entre regiones. Un servicio en una región que habla con una base de datos en otra paga el cruce en cada llamada. Las aplicaciones conversadoras lo vuelven caro de una forma que ningún diagrama muestra.
• Horas de NAT Gateway. Se factura por hora más por gigabyte procesado, y es fácil dejarlo aprovisionado por ambiente cuando la necesidad original ya no existe.
• Private endpoints. Cada uno tiene un cargo por hora. Diez endpoints en tres ambientes son un rubro que no existía hace dos años.
• Gateways de VPN y ExpressRoute. Se dimensionan una vez, para una migración, y no se revisan más.

Ninguno es un error. Todos son invisibles hasta que la factura se agrupa por servicio.

Qué revisar: costo agrupado por servicio y luego por recurso, para los servicios de red en particular.

4. Ambientes que no son producción con ajustes de producción

Desarrollo, staging y QA normalmente se clonan de producción y nunca se redimensionan. Mismo SKU, misma redundancia, misma retención, misma política de respaldo, para un ambiente que corre ocho horas al día y no atiende clientes.

El mecanismo es simple. Clonar es la forma segura de construir un ambiente, y redimensionar es una tarea aparte que nadie tiene asignada. La redundancia es la parte cara, porque las opciones zone-redundant y geo-redundant multiplican a la vez las líneas de cómputo y de almacenamiento.

Qué revisar: suscripciones agrupadas por etiqueta de ambiente, con el SKU y el nivel de redundancia al lado del equivalente de producción.

5. Licenciamiento y telemetría

Aquí se esconden dos cargos.

El primero es licenciamiento. Windows Server y SQL Server llevan un costo de licencia dentro del precio de la VM. Cuando la organización ya tiene Software Assurance o licencias por suscripción con hybrid benefit disponible, ese costo se paga dos veces hasta que se aplica el beneficio. Es configuración, no arquitectura.

El segundo es telemetría. Log Analytics se factura por ingesta y por retención. Un workspace al que le dieron un tope diario generoso durante un incidente, y nunca lo devolvieron, sigue facturando después de cerrar el incidente. El logging verboso que se activó para depurar una noche rara vez se apaga.

Qué revisar: estado de hybrid benefit por VM, e ingesta por workspace por día contra el tope configurado.

La revisión de una hora

Cinco pasos, sin herramientas y sin comprar nada. Si tienes el portal abierto, puedes correrla tú mismo hoy:

1. Agrupa el costo por servicio de los últimos tres meses. Anota los servicios que crecieron más rápido que el uso.
2. Agrupa por recurso dentro de esos servicios. Ordena por costo y lee los primeros veinte.
3. Lista los discos sin adjuntar y los snapshots más viejos que la política de retención.
4. Saca CPU y memoria P95 de las diez VM más caras. Compáralas con el SKU.
5. Revisa el estado de hybrid benefit y el tope diario de cada workspace de Log Analytics.

Lo que buscas no es un error grande. Son cuatro o cinco rubros medianos sin dueño, que es justo la razón por la que sobrevivieron al último recorte de presupuesto.

Si la revisión te deja más preguntas que respuestas, es normal. El siguiente paso es una evaluación de solo lectura: mapeamos los cinco rubros a tu suscripción, cuantificamos cada uno, y te dejamos la lista con o sin que nos contrates.