Azure Functions: Consumption, Flex sau Premium — și cât costă de fapt să scapi de cold start

Întrebarea cu care începe aproape orice discuție despre planurile de Azure Functions e „care e mai ieftin?”. E o întrebare greșită, pentru că are un răspuns care nu ajută pe nimeni: depinde.

Întrebarea corectă e: de la ce volum de trafic plata pe execuție devine mai scumpă decât capacitatea rezervată — și cât plătesc, în bani reali, ca să elimin cold start-ul? Asta are un răspuns numeric, iar în majoritatea cazurilor răspunsul e surprinzător.

În articolul anterior am vorbit despre cele trei tipuri de cost dintr-o arhitectură cloud. Planurile de Functions sunt cel mai curat exemplu din Azure al tensiunii dintre cost variabil și cost fix, așa că e un loc bun de început.

Cele patru opțiuni, pe scurt

Peisajul s-a schimbat în ultimii doi ani și mulți încă raționează cu harta veche, în care existau doar Consumption și Premium.

Consumption (clasic)

Serverless în sensul pur. Scalează la zero, plătești per execuție și per GB-secundă de memorie consumată. Limitări: fără integrare VNet, maximum 10 minute per execuție, memorie plafonată, cold start-uri de câteva secunde.

Flex Consumption

Devenit general disponibil în 2024 și recomandarea implicită a Microsoft pentru workload-uri serverless noi. Păstrează scalarea la zero, dar adaugă exact lucrurile pentru care lumea fugea la Premium: integrare VNet, instanțe always-ready configurabile (de la 0 în sus), execuții de până la 60 de minute, memorie per instanță mai mare și o limită de scale-out semnificativ mai ridicată.

Premium (Elastic Premium, EP1–EP3)

Capacitate rezervată, pre-încălzită. Zero cold start, VNet complet, deployment slots, execuții practic nelimitate ca durată. Se facturează per core-secundă și memorie, pentru instanțele necesare și pentru cele pre-încălzite — cel puțin una trebuie să rămână caldă permanent. Cu alte cuvinte: plătești și la trafic zero.

Dedicated (App Service Plan)

Rulezi funcțiile pe un App Service Plan existent. Nu se facturează separat. Are sens într-un singur scenariu, dar acolo are mult sens — revin la el mai jos.

Formula pragului de rentabilitate

Hai să punem cifre. Modelul de facturare pe Consumption are doi termeni, iar ambii au un nivel gratuit permanent lunar: 1.000.000 de execuții și 400.000 GB-secunde.

GB-secunde = (Memorie_MB / 1024) × Durata_secunde × Execuții

Cost_execuții = max(0, Execuții - 1.000.000) × $0,0000002
Cost_compute  = max(0, GB-s - 400.000)      × $0,000016

Total = Cost_execuții + Cost_compute

Un plan Premium EP1 care rulează o instanță permanent ajunge, orientativ, undeva în zona a 150–170 de dolari pe lună, indiferent de trafic. Pragul de rentabilitate e volumul la care Consumption atinge suma asta.

Scenariul A: API mic, funcții rapide

512 MB memorie, 200 ms durată medie.

Fiecare execuție consumă 0,1 GB-secunde. Costul marginal per execuție e de aproximativ 0,0000018 dolari. Ca să ajungi la 160 de dolari pe lună, ai nevoie de aproape 90 de milioane de execuții lunar — adică peste 30 de cereri pe secundă, susținut, 24/7.

Dacă ai traficul ăsta, probabil nu citești un articol despre optimizarea costurilor. Concluzia pentru marea majoritate a aplicațiilor: Premium nu se justifică niciodată din motive de cost la acest profil.

Scenariul B: procesare, funcții grele

1 GB memorie, 2 secunde durată medie.

Fiecare execuție consumă 2 GB-secunde. Costul marginal urcă la circa 0,0000322 dolari per execuție, iar pragul coboară dramatic: în jur de 5 milioane de execuții pe lună, adică aproximativ 2 pe secundă.

Diferența dintre cele două scenarii e de aproape douăzeci de ori, iar variabila care o produce nu e numărul de execuții — e produsul dintre memorie și durată. Aici e toată optimizarea.

Pe Consumption nu plătești pentru trafic. Plătești pentru GB-secunde. Două arhitecturi cu același număr de cereri pot avea facturi complet diferite.

Cât costă, în bani, să elimini cold start-ul

Aici e adevărata decizie, și rareori e pusă în termeni onești.

Pe Consumption clasic, un cold start pe .NET înseamnă, realist, câteva secunde de latență pentru prima cerere după o perioadă de inactivitate. Dacă funcția servește un webhook, un job de noapte sau un procesator de coadă, nu contează absolut deloc. Dacă servește un endpoint pe care îl apelează interfața utilizatorului, contează foarte mult.

Varianta veche era: accepți cold start-ul sau plătești ~160 de dolari pe lună pentru Premium. Un salt de la aproape zero la un cost fix consistent, ca să rezolvi o problemă care se manifestă poate de 40 de ori pe zi.

Flex Consumption a spart exact acest fals binar. Configurezi un număr de instanțe always-ready — poate fi una singură — și plătești pentru ele ca pentru capacitate rezervată, în timp ce restul traficului scalează elastic și se facturează pe consum. Cu alte cuvinte, cumperi doar cantitatea de căldură de care ai nevoie, nu un plan întreg.

Pentru un API intern cu trafic modest dar sensibil la latență, asta e aproape întotdeauna alegerea corectă în 2026.

Când merită totuși Premium

Premium rămâne răspunsul corect în câteva situații, și niciuna nu ține de volum:

• Memorie peste ce oferă Flex per instanță — procesări care chiar au nevoie de multă memorie într-un singur proces.
• Deployment slots complete — dacă strategia ta de release depinde de slot swap cu warm-up, Premium e singurul care ți-o dă fără compromisuri.
• Consolidare — un singur plan Premium poate găzdui mai multe function apps. Dacă ai opt aplicații mici care toate au nevoie de VNet și zero cold start, un EP1 partajat poate fi mai ieftin decât opt configurații separate.
• Predictibilitate contractuală — un cost fix cunoscut poate fi preferabil unuia variabil chiar dacă media e mai mare. E o decizie de business validă, nu una tehnică.

Și cazul Dedicated

Dacă ai deja un App Service Plan care rulează 24/7 pentru un API web și e la 15% CPU, funcțiile tale de background pot rula acolo fără niciun cost suplimentar. Capacitatea e deja plătită. E singura situație în care Dedicated e evident corect — și e surprinzător de frecventă.

Trei greșeli care scumpesc facturile de Functions

1. Memorie supradimensionată „ca să fie sigur”

Memoria intră direct în formulă, liniar. O funcție configurată la 1 GB care folosește de fapt 300 MB plătește de trei ori mai mult decât trebuie, pentru fiecare execuție, la infinit. E cea mai ieftină optimizare posibilă: te uiți la metrici și ajustezi.

2. Durata care e de fapt așteptare

Asta e cea mai costisitoare greșeală de cod din serverless. Dacă funcția ta face un apel HTTP sincron și blochează thread-ul trei secunde, plătești trei secunde de GB-secunde ca să aștepți un server care nu e al tău.

// Scump: blochează instanța cât durează I/O-ul
var response = httpClient.GetAsync(url).Result;

// Corect: eliberează thread-ul
var response = await httpClient.GetAsync(url);

Pe Consumption, async/await nu mai e doar o chestiune de scalabilitate — e o linie directă pe factură.

3. Trigger-uri care nu fac batching

O funcție declanșată de o coadă care procesează mesajele unul câte unul plătește costul fix per execuție de N ori. Aceeași funcție configurată să primească loturi plătește o dată. Pentru trigger-uri de volum mare, batchSize din host.json e unul dintre cei mai eficienți parametri din tot Azure:

{
  "version": "2.0",
  "extensions": {
    "queues": {
      "batchSize": 32,
      "newBatchThreshold": 16
    }
  }
}

Arborele de decizie

Comprimat la esențial, pentru un proiect nou în 2026:

1. Ai deja un App Service Plan subutilizat? Rulează funcțiile acolo. Cost marginal zero.
2. Ai nevoie de VNet, private endpoints sau execuții peste 10 minute? Flex Consumption. Nu mai e nevoie de Premium pentru asta.
3. Latența primei cereri contează pentru utilizator? Flex Consumption cu una sau două instanțe always-ready.
4. Trafic sporadic, background, webhook-uri, job-uri? Flex Consumption cu zero instanțe always-ready. Practic gratuit sub nivelul gratuit lunar.
5. Cerințe speciale de memorie, slots sau consolidare pe multe aplicații? Abia aici Premium.

Observi că „am trafic mare” nu apare nicăieri ca motiv pentru Premium. Nu e o omisiune.

Concluzie

Decizia între planurile de Azure Functions e rareori despre volum și aproape întotdeauna despre trei lucruri: cerințe de rețea, toleranță la latența primei cereri și profilul memorie × durată al codului tău.

Înainte să compari planuri, măsoară al treilea element. O funcție care rulează în 200 ms cu 256 MB are un model economic complet diferit de una care rulează în 3 secunde cu 1 GB — și, în cele mai multe cazuri, optimizarea codului aduce mai mult decât schimbarea planului.

În articolul următor trecem la containere: cum funcționează scale-to-zero în Azure Container Apps, de ce minReplicas e cel mai scump parametru cu valoare implicită din Azure și cum configurezi regulile de autoscale în App Service fără să plătești pentru vârfuri care nu vin.

Notă: cifrele de mai sus sunt orientative, pentru regiunea East US, la momentul scrierii. Prețurile diferă pe regiuni și se actualizează — verifică întotdeauna în Azure Pricing Calculator pentru scenariul tău concret.