Da dove partire
Quando la bolletta Azure cresce senza modifiche applicative evidenti, il problema raramente è "Azure costa troppo" in senso astratto. Nella pratica l'aumento è quasi sempre riconducibile a una combinazione precisa di cambio SKU, traffico in uscita, backup più pesanti del previsto, retention estese o risorse rimaste attive dopo un progetto.
Controlli prioritari
- Cost Analysis per subscription e resource group — confronta l'ultimo mese con la baseline precedente, poi scendi al livello risorsa per identificare il delta principale.
- Servizi con pricing variabile — Azure Firewall, NAT Gateway, Log Analytics, backup, bandwidth e dischi premium sono tra i primi candidati quando i costi crescono in modo non lineare.
- Tagging incompleto — senza tag coerenti per owner, ambiente e centro di costo, il costo sembra diffuso e diventa difficile attribuirlo al team giusto.
- Risorse orphaned — public IP, snapshot, managed disk non collegati, NIC residue, vecchi App Service Plan e ambienti di test dimenticati sono una causa frequente.
Pattern ricorrenti
I casi più comuni sono: VM ridimensionate verso SKU più costose durante un incidente e mai riportate indietro; workspace Log Analytics con ingestion cresciuta per log verbosi; backup che includono più workload del previsto; traffico cross-region o verso Internet aumentato dopo una modifica di routing; risorse di staging lasciate attive fuori orario.
Esito utile
Un assessment serio deve produrre un elenco prioritizzato di quick win, separando risparmi immediati da interventi strutturali. Ridurre retention indiscriminate, spegnere ambienti non usati, correggere SKU sovradimensionate e introdurre tagging obbligatorio sono spesso le prime azioni ad alto impatto.