Este artículo cuenta cómo se pone orden en un tenant de Azure con varias suscripciones y un límite de gasto que no es negociable. Es un entorno personal de laboratorio y producción ligera, sin equipo de FinOps ni contrato corporativo, y precisamente por eso las decisiones se ven sin ruido.
1. El punto de partida: un tenant que crece solo
Un tenant personal acumula lo que acumula cualquier otro, solo que más rápido y sin nadie que pregunte por qué existe cada cosa: planes de servicio de aplicaciones de tamaño mayor del necesario, máquinas virtuales que nadie recuerda haber creado, recomendaciones que se quedan abiertas. La diferencia con una empresa es que aquí el gasto sale de un bolsillo concreto, y eso obliga a definir un límite antes de empezar a limpiar.
Fijé uno: 120 € al mes en la suscripción de producción. No es una cifra sofisticada; es el techo a partir del cual quiero enterarme. El resto del trabajo consistió en entender qué había dentro de ese techo y qué sobraba.
2. Auditar antes de tocar
Antes de borrar nada hice dos pasadas de inventario y revisión. Una con ARI (Azure Resource Inventory), para tener la lista real de recursos de cada suscripción, y otra con AZQR (Azure Quick Review), la herramienta de línea de comandos que analiza los recursos frente a las buenas prácticas de Azure y devuelve los hallazgos de configuración que no cumplen. La documentación de Microsoft la presenta como una revisión de alineamiento con recomendaciones, distinta de Azure Policy y de Azure Advisor, y es una distinción útil: cada una ve cosas diferentes.
Resultado de la auditoría: de 24 hallazgos a 2 tras la limpieza y los ajustes. No incluyo aquí la lista, porque los hallazgos concretos dependen de cada tenant; lo relevante es el orden. Primero se mide, después se decide, y solo al final se borra.
3. Dónde estaba el dinero
Los ahorros salieron de tres decisiones, ninguna sofisticada:
| Decisión | Ahorro aproximado | Qué había detrás |
|---|---|---|
| Bajar de plan de servicio | ~33 €/mes | Un plan de tamaño superior al necesario |
| Borrar un plan P0v3 sin uso | ~70 €/mes | Un plan sin uso que seguía facturando |
| Borrar 3 máquinas virtuales huérfanas | No cuantificado por separado | Máquinas sin propietario identificable |
Son cifras aproximadas de mi tenant, redondeadas, no un benchmark. Lo que conviene retener es el patrón: el gasto evitable estaba en recursos que seguían existiendo por inercia, no en la facturación del trabajo útil. La propia documentación de Advisor incluye entre sus recomendaciones de coste, en vista previa, la de «plan de App Service sin aplicaciones»; una señal barata que merece mirarse en cualquier tenant.
4. Dos sorpresas que costaron tiempo
4.1 Recomendaciones fantasma
Tras borrar varios recursos, Advisor seguía mostrando recomendaciones sobre ellos. Es una trampa de lectura: si no se comprueba el inventario real, se acaba «arreglando» algo que ya no existe o dudando de una limpieza que sí funcionó. La regla que adopté es que el inventario manda, y Advisor se contrasta contra él. Una recomendación sobre un recurso que ya no figura en el inventario es ruido, y se descarta o pospone, no se persigue.
4.2 Un ajuste huérfano que bloquea el cambio de plan
Al bajar de SKU, el cambio quedó bloqueado por un ajuste huérfano de «File Change Audit». No bastaba con elegir el plan menor: había que localizar y retirar antes ese ajuste. Es un ejemplo de por qué conviene registrar la configuración de los recursos junto con su tamaño: una bajada de plan no siempre es un cambio de un solo campo. No he verificado en la documentación de Microsoft el mecanismo exacto de ese bloqueo, así que lo cuento como lo que observé, no como un comportamiento documentado.
5. El límite como código: presupuestos con alertas
Con la limpieza hecha, el límite de 120 € necesitaba un mecanismo. Los presupuestos de Cost Management hacen exactamente eso, con tres matices que la documentación deja claros y que conviene tener presentes:
- Avisan, no frenan. Al superar un umbral se envían notificaciones; los recursos no se ven afectados y el consumo no se detiene.
- Tienen latencia. Los datos de coste suelen estar disponibles en 8–24 horas y los presupuestos se evalúan cada 24 horas; cuando se alcanza un umbral, el correo suele enviarse en la hora siguiente al análisis.
- Admiten umbrales reales y previstos. Un presupuesto necesita al menos un umbral y un correo, y admite hasta cinco de cada. Los umbrales de coste previsto avisan antes de llegar al límite.
La combinación que uso es: 80 % real, 100 % real y 100 % previsto. La alerta prevista es la que anticipa; la de 100 % real es la que confirma. Es el mismo principio del artículo sobre la latencia del dato de consumo: el presupuesto es una alarma, no un freno, y su valor depende de cuánto tarda en llegar el dato.
5.1 Por qué por plantilla y no por línea de comandos
Crear el presupuesto con la CLI me dio errores que no he reproducido al redactar esto, pero la documentación explica una parte del porqué. Con la versión 2.91.0 de la CLI de Azure (comprobada el 3 de noviembre de 2026), el comando az consumption budget create está en vista previa y no expone parámetros para notificaciones ni para umbrales. La variante create-with-rg sí acepta un diccionario de notificaciones, pero está pensada para un grupo de recursos y el ejemplo oficial no incluye el tipo de umbral. El comando update exige el eTag más reciente, que hay que obtener antes con una lectura. Y la propia página de Microsoft sobre presupuestos recomienda usar las API REST para crear y editar presupuestos «porque los comandos de la CLI pueden no admitir la última versión de las API».
La salida limpia es un despliegue declarativo a nivel de suscripción, que sí admite el tipo de umbral Forecasted en la API 2023-11-01. Esta es la plantilla que uso, validada con az deployment sub validate el 3 de noviembre de 2026 (sustituye el correo y la fecha de inicio, que debe ser el primer día de un mes):
{
"$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"budgetName": { "type": "string", "defaultValue": "budget-limite-mensual" },
"amount": { "type": "int", "defaultValue": 120 },
"startDate": { "type": "string", "defaultValue": "2026-11-01" },
"email": { "type": "string" }
},
"resources": [{
"type": "Microsoft.Consumption/budgets",
"apiVersion": "2023-11-01",
"name": "[parameters('budgetName')]",
"properties": {
"category": "Cost",
"amount": "[parameters('amount')]",
"timeGrain": "Monthly",
"timePeriod": { "startDate": "[parameters('startDate')]" },
"notifications": {
"actual_80": { "enabled": true, "operator": "GreaterThanOrEqualTo", "threshold": 80,
"thresholdType": "Actual", "contactEmails": [ "[parameters('email')]" ] },
"actual_100": { "enabled": true, "operator": "GreaterThanOrEqualTo", "threshold": 100,
"thresholdType": "Actual", "contactEmails": [ "[parameters('email')]" ] },
"forecast_100": { "enabled": true, "operator": "GreaterThanOrEqualTo", "threshold": 100,
"thresholdType": "Forecasted", "contactEmails": [ "[parameters('email')]" ] }
}
}
}]
}Se despliega con az deployment sub create --location <región> --template-file budget.json --parameters email=<correo>. Dos advertencias: validar no es lo mismo que desplegar y comprobar que las alertas llegan, y esta plantilla es un punto de partida, no un módulo endurecido. Declarar el presupuesto como código tiene la ventaja de que el límite queda versionado y se puede reponer si alguien lo borra.
6. Trade-offs que hay que decidir explícitamente
| Decisión | Beneficio | Coste o riesgo | Criterio |
|---|---|---|---|
| Límite bajo y fijo | Fuerza a revisar el gasto cada mes | Falsas alarmas si hay picos legítimos | Fijarlo con un margen sobre el consumo real, no sobre el deseado |
| Alerta prevista además de la real | Aviso antes de llegar al techo | Puede avisar de un mes que acaba bien | Mantenerla: prefiero un aviso de más |
| Borrar rápido | Ahorro inmediato | Perder algo que se usaba | Inventario y propietario identificados antes de borrar |
| Confiar en Advisor | Señales baratas | Recomendaciones sobre recursos ya borrados | El inventario manda; Advisor se contrasta |
7. Qué hacer el lunes
- Fija un límite mensual por suscripción y escríbelo. Sin cifra no hay alerta que valga.
- Haz un inventario y una revisión de buenas prácticas antes de borrar, y guarda el resultado como línea base.
- Busca lo evidente primero: planes sin aplicaciones, máquinas virtuales sin propietario, discos sin asociar.
- Declara el presupuesto como código a nivel de suscripción, con un umbral real y otro previsto, y comprueba que el correo llega.
- Contrasta Advisor con el inventario antes de actuar sobre cualquier recomendación.
Las opiniones expresadas en este artículo son personales.
Fuentes
Páginas y comandos consultados el 3 de noviembre de 2026 (CLI de Azure 2.91.0). Los comportamientos de la CLI y de las API cambian con frecuencia: conviene revalidarlos antes de usarlos.
- Microsoft Learn. Tutorial: Create and manage budgets
- Microsoft Learn. Microsoft.Consumption budgets 2023-11-01 (plantilla ARM)
- Microsoft Learn. az consumption budget
- Microsoft Learn. Azure Advisor: cost recommendations
- Microsoft Learn. Azure Quick Review (azqr)