Ultimul pas din optimizarea costurilor în Azure e și cel mai ușor de făcut greșit, pentru că e singurul care nu se poate anula.
Rezervările și planurile de economii sunt instrumente financiare, nu tehnice. Nu schimbă nimic în arhitectura ta — schimbă doar prețul pe care îl plătești pentru exact aceleași resurse, în schimbul unui angajament pe unul sau trei ani. Discounturile sunt substanțiale. Și tocmai de asta e important să le cumperi ultimele, nu primele.
Regula de ordine care contează cel mai mult
Înainte de orice detaliu tehnic, o singură regulă, pentru că repară cea mai scumpă greșeală posibilă:
Redimensionezi întâi. Cumperi angajamente pe urmă.
O rezervare de trei ani pe o mașină supradimensionată înseamnă că ai obținut un discount consistent pe o resursă de care nu aveai nevoie — și ai blocat greșeala pentru 36 de luni. Discountul creează iluzia optimizării exact în momentul în care ai instituționalizat risipa.
De asta seria asta e în ordinea asta. Articolele precedente au fost despre a te asigura că plătești pentru resursele potrivite, la dimensiunea potrivită. Abia acum are sens să discutăm cât plătești pentru ele.
Corolar practic: dacă infrastructura ta are sub șase luni sau trece printr-o migrare, nu cumpăra nimic încă. Ai nevoie de date de utilizare stabile ca să alegi corect. Costul de a aștepta câteva luni pe pay-as-you-go e aproape întotdeauna mai mic decât costul unui angajament greșit.
Cele trei instrumente
Pay-as-you-go
Prețul de listă. Plătești ora consumată, nu te angajezi la nimic, poți opri oricând. E scump, dar e singurul care nu costă nimic dacă te răzgândești.
Are un rol permanent în orice strategie sănătoasă: acoperă vârfurile și partea variabilă a consumului, adică exact porțiunea pe care nu vrei să o comiți.
Reserved Instances
Te angajezi la o resursă specifică — o familie de mașini, într-o anumită regiune — pe 1 sau 3 ani. În schimb primești cel mai adânc discount disponibil, care poate ajunge, orientativ, până în zona a 72% față de prețul de listă pe termenul de trei ani.
Se aplică automat, fără să schimbi nimic în configurație: Azure potrivește rezervarea cu resursele eligibile care rulează și facturează diferența la rata redusă.
Punctul important, des ratat: rezervările nu acoperă doar mașini virtuale. Există capacitate rezervată și pentru Azure SQL Database, Cosmos DB și alte servicii cu stare — iar acolo economiile sunt frecvent cele mai mari din tot portofoliul, pentru că bazele de date sunt cele mai stabile resurse pe care le ai.
Savings Plans for Compute
Te angajezi la o sumă pe oră, nu la o resursă. Spui „voi cheltui cel puțin 5 dolari pe oră pe compute” și Azure aplică automat discountul pe consumul eligibil, până la nivelul comitat.
Discountul e mai mic — orientativ până la aproximativ 65% pe trei ani — dar flexibilitatea e mult mai mare: se aplică transversal peste familii de mașini, peste regiuni și peste servicii de compute, inclusiv App Service și planurile Premium de Functions.
Consumul care depășește angajamentul se facturează la prețul normal. Angajamentul neatins se plătește oricum.
Comparația care contează
| Dimensiune | Reserved Instances | Savings Plans |
|---|---|---|
| Te angajezi la | O resursă specifică (familie + regiune) | O sumă pe oră |
| Discount maxim orientativ | ~72% (3 ani) | ~65% (3 ani) |
| Flexibilitate regiune | Nu | Da |
| Flexibilitate serviciu | Nu | Da (compute eligibil) |
| Acoperă servicii cu stare (SQL, Cosmos) | Da, prin rezervări dedicate | Nu |
| Anulare | Posibilă, cu limitări și plafon anual | Nu |
| Efort de administrare | Mai mare — urmărești potrivirea | Mai mic — se aplică singur |
Două detalii operaționale merită reținute:
- Ordinea de aplicare. Când ambele sunt eligibile pentru același consum, rezervările se aplică primele, fiind mai avantajoase. Nu trebuie să gestionezi asta manual.
- Asimetria la ieșire. Rezervările pot fi, în anumite condiții, schimbate sau rambursate parțial. Planurile de economii, nu. Un Savings Plan e o obligație fermă până la finalul termenului — ceea ce face ca subdimensionarea lui deliberată să fie strategia prudentă.
Strategia în straturi
Aici e ideea centrală a articolului: cele trei instrumente nu sunt alternative între care alegi. Sunt straturi pe care le suprapui peste profilul tău de consum.
Imaginează-ți graficul consumului tău lunar. Are o bază care nu coboară niciodată sub un anumit nivel, o zonă intermediară care variază previzibil și niște vârfuri ocazionale.
Stratul 1 — baza dură: Reserved Instances
Resursele care rulează 24/7 de peste șase luni, în aceeași regiune, fără planuri de migrare. Baza de date de producție. Mașinile din spatele unui serviciu matur. Aici cumperi discountul maxim, pe trei ani dacă ești sigur, pe un an dacă nu.
Stratul 2 — consumul stabil dar mobil: Savings Plans
Deasupra bazei rezervate, un consum de compute care e constant ca volum dar se mișcă între servicii: App Service, containere, funcții Premium, mașini care se redimensionează. Accepți 7 puncte procentuale mai puțin discount în schimbul dreptului de a schimba arhitectura fără să pierzi angajamentul.
Stratul 3 — vârfurile: pay-as-you-go
Restul. Scalarea din vârfuri, mediile efemere, experimentele. Plătești preț întreg pe o porțiune mică din total și păstrezi libertatea completă.
Regula de dimensionare a straturilor: comiți pentru nivelul minim observat, nu pentru media. Uită-te la consumul din ultimele șase luni și comite la nivelul sub care nu ai coborât niciodată. Un angajament neutilizat e bani aruncați cu certitudine, în timp ce consumul necomitat e doar bani plătiți la preț întreg. Asimetria e clară.
Patru greșeli costisitoare
1. Cumperi înainte să redimensionezi
Deja discutată, dar e prima din motive întemeiate. Ordinea contează mai mult decât instrumentul.
2. Comiți pe medie, nu pe minim
Dacă media ta e 10 dolari pe oră dar minimul e 6, un angajament de 10 înseamnă că plătești pentru 4 dolari pe oră de capacitate neutilizată în toate perioadele de sub medie. Discountul se evaporă rapid sub o utilizare slabă a angajamentului.
3. Cumperi 3 ani implicit
Termenul de trei ani aduce un discount semnificativ mai bun. Merită doar dacă ai o convingere reală că arhitectura ta va arăta la fel în 2029. Pentru o echipă care migrează activ către containere sau serverless, un an e alegerea onestă.
4. Uiți serviciile cu stare
Discuția publică e dominată de mașini virtuale, dar pentru o aplicație modernă baza de date e adesea cea mai mare și cea mai stabilă linie din factură. Capacitatea rezervată pentru Azure SQL sau throughput-ul rezervat în Cosmos DB sunt frecvent cele mai profitabile achiziții din tot exercițiul — și cele mai des ignorate.
Recapitularea seriei
Cu asta încheiem cele cinci articole despre optimizarea costurilor în Azure. Firul roșu, dacă ar fi să îl comprim:
- Anatomia costului — cost fix, variabil și idle; cel din urmă e cel care produce facturile-surpriză. Măsoară în cost per unitate de business, nu în dolari pe lună.
- Azure Functions — decizia între planuri ține de rețea, latență și profilul memorie × durată, aproape niciodată de volum. Flex Consumption a eliminat falsul binar dintre cold start și plan Premium.
- Auto-scaling —
minReplicasși pragul KEDA sunt cei mai scumpi doi parametri din Container Apps. Valorile implicite sunt alese ca să nu te supere, nu ca să te coste puțin. - Cost Management — fără tagging automat, restul instrumentelor produc numere neatribuibile. Alerte pe cost prognozat, audit lunar de douăzeci de minute.
- Angajamente — ultimul pas, nu primul. În straturi, dimensionate pe minim.
Ce leagă toate cele cinci: optimizarea costurilor nu e o operațiune de urgență declanșată de o factură mare. E o proprietate a arhitecturii și un proces cu ritm propriu — la fel ca securitatea sau observabilitatea, și la fel de dificil de adăugat retroactiv.
Cea mai bună veste e că cea mai mare parte din economii nu vine din negocieri sau din instrumente scumpe. Vine din trei lucruri banale: să nu plătești pentru ce nu folosești, să nu ții cald ce poate fi rece și să te uiți la factură o dată pe lună.
Notă: procentele de discount sunt orientative și variază în funcție de serviciu, regiune, termen și tipul contractului. Verifică valorile concrete în portal înainte de orice achiziție.