Anatomia costului în Azure: unde se duc banii de fapt

Există un moment prin care trece aproape orice echipă care rulează în cloud: factura de luna asta e cu 30% mai mare decât cea de luna trecută, traficul e identic, nimeni nu a deployat nimic major. Și nimeni nu știe exact de ce.

Nu e un bug. E consecința firească a unui model de facturare în care resursele se creează în trei secunde și se uită pentru totdeauna — iar feedback-ul financiar vine cu 30 de zile întârziere, pe un ecran pe care developerul nu îl deschide niciodată.

Acesta e primul articol dintr-o serie de cinci despre optimizarea costurilor în Azure. Înainte să vorbim despre planuri de Functions, reguli de auto-scaling sau rezervări pe trei ani, avem nevoie de un model mental corect. Altfel optimizăm zgomot.

Cele trei tipuri de cost dintr-o arhitectură cloud

Orice linie de pe factura ta intră într-una din trei categorii. Diferența dintre ele nu e contabilă — e arhitecturală, pentru că fiecare se repară altfel.

1. Cost fix (capacitate rezervată)

Plătești pentru capacitate alocată, indiferent dacă o folosești. Un App Service Plan în tier P1v3, un workload profile Dedicated în Container Apps, o mașină virtuală, un plan Premium de Functions. Ceasul merge și la 3 dimineața, când nu te vizitează nimeni.

Costul fix nu e rău în sine — e predictibil, elimină cold start-urile și îți dă control. Devine problematic doar când capacitatea rezervată nu corespunde cu utilizarea reală.

2. Cost variabil (consum efectiv)

Plătești per execuție, per GB-secundă, per Request Unit, per gigabyte transferat. Azure Functions pe Consumption, Cosmos DB serverless, Container Apps pe profil Consumption. La zero trafic, plătești aproape zero.

Aici capcana e inversă: costul e invizibil până devine mare. O funcție care rulează de 200 de ori pe minut în loc de 2 nu apare în niciun alert — apare doar pe factură.

3. Cost idle (cel mai scump zero din lume)

Asta e categoria pe care o ratează toată lumea. Idle cost e ce plătești pentru resurse care rulează, dar nu fac nimic util.

Exemplul canonic e în Azure Container Apps. Serviciul poate scala la zero replici, caz în care nu plătești compute. Dar în momentul în care setezi minReplicas: 1 — de obicei ca să eviți cold start-ul — fiecare replică rulează 24/7 și e facturată la o rată de idle, separată de rata active aplicată în timp ce se procesează efectiv o cerere.

Diferența dintre cele două rate e de ordinul unui factor de opt. Sună puțin. Înmulțit cu 730 de ore pe lună, pentru trei microservicii, în trei medii (dev, staging, prod), nu mai e puțin.

Majoritatea facturilor-surpriză din Azure nu vin din trafic. Vin din timp idle pe resurse pe care cineva a decis, acum șase luni, că e mai sigur să nu scaleze la zero.

De ce developerul nu vede costul

Într-o aplicație clasică on-premise, resursa e fizică și finită. Dacă serverul nu mai are RAM, afli imediat — aplicația moare. Feedback-ul e brutal, dar instantaneu.

În cloud, resursa e elastică. Dacă ai nevoie de mai mult RAM, platforma ți-l dă. Aplicația nu moare. Nimic nu se strică. Costul suplimentar apare peste trei săptămâni, într-un raport pe care îl citește altcineva, agregat cu alte 400 de linii.

Bucla de feedback e ruptă în trei locuri:

• Temporal — efectul deciziei apare la 30 de zile după decizie.
• Organizațional — cine ia decizia tehnică nu e cine vede factura.
• Granular — factura e per subscripție, decizia e per resursă.

Tot ce urmează în seria asta e, în esență, despre repararea acestor trei rupturi. Tagging-ul rezolvă granularitatea. Budgets și anomaly alerts rezolvă temporalitatea. Restul e arhitectură.

Cele cinci surse de risipă pe care le găsești aproape sigur

Dacă deschizi acum Cost Analysis pe o subscripție care rulează de peste un an, probabilitatea să găsești cel puțin trei dintre astea e foarte mare.

1. Resurse orfane

Discuri neatașate rămase după ștergerea unei VM. Adrese IP publice rezervate și nefolosite. Snapshot-uri din 2023. NAT Gateway-uri pentru un VNet gol. Load balancere fără backend. Niciuna nu face nimic, toate se facturează.

2. Medii non-producție care rulează 24/7

Dev și staging sunt folosite, realist, 40 de ore pe săptămână. Se facturează 168. Asta înseamnă că 76% din costul mediilor non-prod e cheltuit în timp ce nimeni nu se uită la ele. Un simplu schedule de start/stop e, procentual, cea mai profitabilă oră de muncă pe care o poți investi în infrastructură.

3. Over-provisioning „pentru siguranță”

Cineva a ales P2v3 în loc de P1v3 la lansare, ca să fie sigur. Nu a măsurat niciodată. Aplicația rulează la 12% CPU de doi ani. Azure Advisor semnalează asta, dar nu îl citește nimeni.

4. Observabilitate necalibrată

Application Insights și Log Analytics se facturează per gigabyte ingerat. Un LogLevel.Information lăsat în producție pe un endpoint cu trafic mare poate ajunge, în linii de factură, comparabil cu compute-ul aplicației care generează logurile. E un mod deosebit de ironic de a cheltui bani.

5. Egress și chattiness între regiuni

Transferul de date în Azure e gratuit. Afară din Azure, nu. Iar traficul între regiuni se facturează la fel. O arhitectură în care API-ul e în West Europe și baza de date în North Europe „pentru redundanță” plătește pentru fiecare query, la infinit.

Modelul mental care schimbă discuția

Cel mai util lucru pe care l-am adoptat e să nu mai măsor costul în dolari pe lună, ci în cost per unitate de business.

„Infrastructura ne costă 800 de dolari pe lună” e o afirmație care nu se poate acționa. Nu știi dacă e mult sau puțin. Nu știi dacă e în creștere sănătoasă sau în derivă.

„Ne costă 1,40 dolari per tenant activ pe lună” e cu totul altceva. E o metrică pe care o poți urmări în timp, o poți compara cu prețul abonamentului și pe baza căreia poți răspunde la întrebarea care contează de fapt: marja se îmbunătățește sau se erodează pe măsură ce creștem?

Pentru un SaaS, unitatea e tenantul. Pentru un API public, e mia de cereri. Pentru un pipeline de procesare, e documentul procesat. Odată ce ai numitorul, optimizarea încetează să fie o corvoadă și devine o metrică de produs.

Ce urmează în serie

Cu modelul ăsta în cap, următoarele patru articole devin decizii concrete, nu tabele de prețuri:

1. Azure Functions: Consumption, Flex sau Premium — unde e pragul real de la care plata pe execuție devine mai scumpă decât capacitatea rezervată și cât costă, în bani, să elimini cold start-ul.
2. Auto-scaling care nu te costă — KEDA și scale-to-zero în Container Apps, reguli de autoscale în App Service și de ce minReplicas e cel mai scump parametru cu valoare implicită din Azure.
3. Azure Cost Management — tagging, Cost Analysis, budgets, anomaly detection și cum îți construiești un proces de audit lunar care durează 20 de minute.
4. Reserved Instances vs. Savings Plans vs. pay-as-you-go — ce comiți, pe ce termen și de ce aproape niciodată nu alegi un singur instrument.

Concluzie

Optimizarea costurilor în cloud nu e o operațiune de urgență făcută când vine factura mare. E o proprietate a arhitecturii, la fel ca securitatea sau observabilitatea — și, ca ele, e mult mai ieftin să o construiești din start decât să o adaugi ulterior.

Până la articolul următor, un exercițiu de zece minute care merită aproape întotdeauna: deschide Cost Analysis, grupează după Resource, sortează descrescător și uită-te la primele cinci linii. Apoi întreabă-te, pentru fiecare, dacă știi de ce e acolo. Dacă nu ai un răspuns pentru cel puțin una, ai găsit deja prima țintă.