Azure Cost Management: cum identifici și elimini risipa în 20 de minute pe lună

Optimizarea costurilor în cloud eșuează aproape întotdeauna în același fel. Cineva face o curățenie mare, taie 30% din factură, toată lumea e mulțumită — și în șase luni costul e înapoi de unde a plecat, pentru că între timp s-au creat resurse noi și nimeni nu s-a mai uitat.

Diferența dintre o curățenie și un proces e că procesul are un ritm și durează suficient de puțin încât să nu fie amânat. Articolul ăsta e despre construirea acelui proces în Azure.

Până acum am vorbit despre arhitectură: planuri de Functions, reguli de scalare, parametri de configurare. Acum trecem la instrumentar — pentru că, în lipsa vizibilității, toate deciziile de mai devreme se degradează în tăcere.

Pasul zero: tagging, sau de ce nu poți răspunde la nicio întrebare

Deschide Cost Analysis pe o subscripție netaguită și încearcă să răspunzi la: cât ne costă mediul de staging? Sau: cât costă clientul X? Sau: ce parte din factură ține de produsul A față de produsul B?

Nu poți. Poți vedea că ai cheltuit o sumă pe App Service, dar nu poți separa producția de test, pentru că platforma nu știe diferența. Iar o factură pe care nu o poți segmenta e o factură pe care nu o poți acționa.

Tagging-ul e infrastructura pe care stă tot restul. Recomandarea mea: un set minim, aplicat consecvent, e infinit mai valoros decât o taxonomie elaborată pe care o respectă jumătate din echipă.

• Environment — prod / staging / dev
• Application — numele produsului sau serviciului
• Owner — echipa sau persoana responsabilă
• CostCenter — dacă ai nevoie de alocare contabilă

Patru tag-uri. Atât.

Tagging-ul manual nu funcționează

Asta nu e o opinie, e o observație empirică. Orice proces care depinde de disciplina cuiva la ora 18:30, vineri, când creează rapid o resursă pentru un test, va avea lacune.

Soluția e să muți aplicarea în două locuri automate:

În Infrastructure as Code. Dacă resursele se creează prin Bicep sau Terraform, tag-urile sunt parte din definiție și nu pot lipsi:

param environment string
param application string

var standardTags = {
  Environment: environment
  Application: application
  Owner: 'platform-team'
  ManagedBy: 'bicep'
}

resource app 'Microsoft.Web/sites@2023-12-01' = {
  name: appName
  location: location
  tags: standardTags
  properties: { ... }
}

În Azure Policy. Pentru ce scapă, politicile pot moșteni automat tag-urile de la resource group sau pot bloca direct crearea unei resurse fără tag-urile obligatorii. A doua variantă e agresivă, dar funcționează — și e singura care garantează acoperire completă.

Un tag lipsă nu e o problemă de curățenie. E o linie de pe factură la care nu vei putea niciodată răspunde „a cui e?”.

Cost Analysis: cele patru vizualizări care contează

Cost Analysis oferă foarte multe combinații de filtre și grupări. În practică, patru răspund la aproape tot.

1. Grupat după Resource, sortat descrescător

Cea mai simplă și cea mai utilă. Primele cinci–zece linii reprezintă de obicei majoritatea facturii. Întrebarea pentru fiecare: știu de ce e acolo și e proporțional cu valoarea pe care o produce?

2. Grupat după tag-ul Environment

Aici apar surprizele reale. Dacă mediile non-producție depășesc 25–30% din total, ai o problemă de anvergură — și, de obicei, una ușor de rezolvat prin oprire programată.

3. Grupat după Service, pe 6 luni, ca grafic

Valoarea absolută contează mai puțin decât panta. Un serviciu care crește constant fără ca traficul să crească e un semnal. Log Analytics și Application Insights sunt suspecții obișnuiți: cresc odată cu volumul de loguri, nu cu volumul de business.

4. Cost pe unitate de business

Nu există nativ, dar se construiește: exporți costul lunar, îl împarți la numărul de tenanți activi, clienți sau documente procesate, și urmărești seria în timp.

E singura metrică pe baza căreia poți spune dacă arhitectura ta se scalează economic. Costul total crește întotdeauna când crește business-ul — asta nu îți spune nimic. Costul per unitate ar trebui să scadă.

Budgets și alerte: mutarea feedback-ului mai aproape de decizie

În primul articol am spus că bucla de feedback din cloud e ruptă temporal — efectul unei decizii apare 30 de zile mai târziu. Budgets sunt instrumentul care repară asta.

Un budget în Azure nu oprește nimic (deși poate declanșa un Action Group care oprește). E un prag cu alerte. Cheia e să configurezi alerte pe cost prognozat, nu doar pe cost efectiv.

Diferența e esențială: o alertă la 100% din costul efectiv te anunță că ai depășit bugetul — prea târziu. O alertă la 80% din costul prognozat te anunță pe 12 ale lunii că, în ritmul actual, vei depăși bugetul. Ai timp să intervii.

Configurația pe care o folosesc:

• Un budget per mediu, bazat pe tag-ul Environment
• Alertă la 80% din prognozat — avertisment, ajunge pe email
• Alertă la 100% din prognozat — investigație, ajunge și în canalul de echipă
• Alertă la 100% efectiv — escaladare

Anomaly detection: alerta care prinde ce nu ai prevăzut

Budgets prind creșterea lentă. Nu prind saltul brusc într-un serviciu care oricum era mic — pentru că totalul rămâne sub prag.

Detectarea anomaliilor se uită la tipar, nu la valoare absolută. Un serviciu care costa 3 dolari pe lună și ajunge brusc la 40 e o anomalie, chiar dacă 40 de dolari nu declanșează niciun budget. De obicei înseamnă o buclă, un retry fără backoff sau un job care rulează mult mai des decât ar trebui.

E gratuit de activat și e singura alertă care prinde clasa de probleme „ceva s-a stricat și costă bani”.

Vânătoarea de resurse orfane

Categoria asta apare în aproape orice subscripție mai veche de un an, pentru că ștergerile în Azure sunt frecvent parțiale. Ștergi o mașină virtuală, discul rămâne.

Suspecții obișnuiți:

• Discuri neatașate — rămase după VM-uri șterse, facturate integral
• Adrese IP publice rezervate — nefolosite, dar alocate
• Snapshot-uri vechi — create „înainte de migrare”, niciodată curățate
• Load balancere și NAT Gateway fără backend
• App Service Plans goale — aplicațiile șterse, planul rămas, facturat la tier-ul lui

Azure Advisor semnalează o parte dintre ele, dar nu toate. Pentru un inventar rapid, Resource Graph e mai eficient decât orice click prin portal:

resources
| where type =~ 'microsoft.compute/disks'
| where properties.diskState == 'Unattached'
| project name, resourceGroup, location,
          sizeGB = properties.diskSizeGB,
          sku = sku.name
| order by sizeGB desc

Aceeași logică se aplică pentru IP-uri publice fără ipConfiguration sau pentru planuri fără site-uri asociate. Un query salvat, rulat o dată pe lună, acoperă tot.

Auditul lunar de 20 de minute

Aici se leagă totul. Procesul trebuie să fie suficient de scurt încât să nu fie amânat — altfel nu e proces, e intenție.

1. (3 min) Cost Analysis, luna trecută vs. luna anterioară, grupat după Service. Ce a crescut cu peste 15%?
2. (3 min) Grupat după tag-ul Environment. Cât la sută e non-producție?
3. (5 min) Rulează query-urile din Resource Graph pentru resurse orfane. Șterge ce e evident mort.
4. (3 min) Deschide Azure Advisor, secțiunea Cost. Sunt recomandări de right-sizing noi?
5. (3 min) Verifică resursele fără tag-uri. Câte sunt? Cine le-a creat?
6. (3 min) Actualizează metrica de cost per unitate de business. Crește sau scade?

Douăzeci de minute, o dată pe lună, în calendar ca eveniment recurent. Nu e glamour. E singura variantă care funcționează pe termen lung.

Concluzie

Instrumentele din Azure Cost Management sunt bune și, în mare parte, gratuite. Problema nu e niciodată instrumentarul — e că nimeni nu are în calendar momentul în care se uită la el.

Dacă reții un singur lucru din articolul ăsta: aplică tag-urile automat, prin IaC sau Policy. Fără segmentare, restul instrumentelor îți arată numere pe care nu le poți atribui nimănui și, prin urmare, pe care nu le poate acționa nimeni.

În ultimul articol al seriei vorbim despre partea financiară: Reserved Instances, Savings Plans și pay-as-you-go — ce comiți, pe ce termen și de ce strategia corectă e aproape întotdeauna una în straturi, nu o alegere unică.