Modulul 8 s-a încheiat cu practicile operaționale care transformă o platformă de date în ceva ce o echipă chiar poate rula. Modulul 9 deschide cu următorul nivel de seriozitate: platforma trebuie să fie accesibilă financiar. O platformă fiabilă care costă de trei ori mai mult decât se aștepta afacerea va fi tăiată. O platformă ieftină care pierde date costă afacerea mai mult decât economisește vreodată. Costul nu e opusul fiabilității sau performanței; e a treia axă pe care o echipă matură trebuie să o echilibreze.
Lecția aceasta pregătește modulul descriind forma unei facturi cloud. Constatarea principală, pe care fiecare practician FinOps a internalizat-o și majoritatea inginerilor nu, e că compute-ul e doar partea vizibilă. Factura reală e un aisberg, iar partea de sub linia apei e unde trăiesc taxele neașteptate. Storage, egress de rețea, NAT gateway-uri, trafic cross-AZ, numărul de request-uri, ingestia de loguri și o coadă lungă de linii de la servicii gestionate alcătuiesc grosul facturii la majoritatea companiilor mature.
Cadrul contează pentru că pârghiile la care un inginer ajunge instinctiv sunt pârghii de compute. Right-size pentru instanța EC2. Folosește Spot. Scalează în jos noaptea. Astea funcționează, și lecția 67 le acoperă în detaliu. Dar o echipă care se concentrează doar pe compute va rezolva o treime din problemă și va descoperi celelalte două treimi când factura de egress se triplează după ce se livrează o integrare cu un partener.
Cum arată de fapt factura
Sondajele publice, rapoartele vendorilor și rapoartele State of FinOps ale FinOps Foundation converg pe o compoziție aproximativă pentru o companie tipică de mărime medie pe AWS. Procentele exacte variază în funcție de workload, dar forma e recognoscibilă în majoritatea organizațiilor cu volum mare de date.
- Compute (EC2, noduri EKS, Fargate, Lambda, EMR): în jur de 30 la sută.
- Storage (S3, EBS, EFS, snapshots, backup-uri): în jur de 20 la sută.
- Rețea (egress spre internet, procesarea datelor pe NAT Gateway, trafic cross-AZ, transfer inter-region): în jur de 15 la sută.
- Servicii gestionate (RDS, DynamoDB, Aurora, Redshift, Snowflake pe AWS, Kinesis, MSK, OpenSearch): în jur de 15 la sută.
- Elemente adiacente transferului de date (CloudFront, Direct Connect, Transit Gateway, VPC endpoints): în jur de 10 la sută.
- Toate celelalte (unelte de securitate, monitorizare, SaaS terț prin Marketplace, instanțe GPU pentru ML, KMS, Secrets Manager, diverse): cele 10 la sută rămase.
Numerele din rapoartele anuale ale FinOps Foundation (https://www.finops.org/, consultat 2026-05-01) sunt în aceeași zonă, cu variație notabilă pe industrii. Companiile cu volum mare de streaming văd rețeaua urcând peste compute. Companiile cu volum mare de analiză văd storage-ul și cheltuielile de warehouse gestionat dominând. Companiile cu volum mare de ML văd compute-ul GPU și storage-ul atașat la acceleratoare luând o felie mai mare. Raportul anual de prețuri de bandwidth al Cloudflare (https://blog.cloudflare.com/aws-egregious-egress/, consultat 2026-05-01) susține că egress-ul AWS în special e tarifat cu un ordin de mărime peste costul de bază, ceea ce e motivul pentru care Cloudflare R2 și alte object stores cu zero-egress au o piață semnificativă.
Punctul nu e procentele exacte, care se schimbă în timp și între echipe. Punctul e că compute-ul e aproximativ o treime din factură, și echipa care urmărește doar compute-ul urmărește scoreboard-ul greșit.
Aisbergul
flowchart TB
subgraph Visible["Above the waterline (what dashboards show)"]
Compute["EC2 / EKS nodes / Lambda<br/>~30 percent"]
end
subgraph Hidden["Below the waterline (what the bill actually contains)"]
Storage["S3 / EBS / snapshots / backups<br/>~20 percent"]
Network["Egress / NAT / cross-AZ / inter-region<br/>~15 percent"]
Managed["RDS / DynamoDB / Redshift / Kinesis<br/>~15 percent"]
Transfer["CloudFront / Transit Gateway / VPC endpoints<br/>~10 percent"]
Misc["Logs / KMS / Secrets / third-party SaaS<br/>~10 percent"]
end
Visible --> HiddenCâteva linii de sub linia apei merită menționate individual pentru că prind echipele prin surprindere mai mult decât celelalte.
Procesarea datelor pe NAT Gateway. Un NAT Gateway în AWS taxează în jur de 4,5 cenți per gigabyte procesat, peste taxa orară per gateway. Un workload care trage o sută de gigabytes pe zi din S3 printr-un NAT Gateway, în loc de printr-un VPC endpoint, costă în jur de 135 de dolari pe lună doar pentru taxa de procesare a datelor, și asta e un singur workload. Înmulțit pe o flotă, o configurație lipsă de VPC endpoint poate adăuga mii de dolari pe lună pentru trafic care ar trebui să fie gratuit. Paginile de prețuri AWS (https://aws.amazon.com/vpc/pricing/, consultat 2026-05-01) au cifrele canonice.
Trafic cross-AZ. AWS taxează aproximativ 1 cent per gigabyte în fiecare direcție pentru traficul între availability zones din aceeași regiune, pentru un dus-întors de 2 cenți per gigabyte. O rețea de microservicii foarte vorbăreață peste trei AZ-uri poate genera terabytes pe zi de chatter cross-AZ. O echipă care rulează Kafka cu broker-i în trei AZ-uri și consumatori în trei AZ-uri plătește pentru fiecare mesaj replicat și consumat care trece o limită de AZ. Producătorii și consumatorii topology-aware (rack-awareness în Kafka, rutare zone-aware în service mesh-uri) există tocmai pentru a ține acest cost sub control.
Egress spre internet. Traficul outbound de la AWS spre internetul public rulează în jur de 9 cenți per gigabyte pentru primul tier, scăzând cu volumul dar nemaiajungând niciodată la zero. Un workload care face backfill cu un terabyte la un partener e o cheltuială unică de 90 de dolari pe care nimeni n-o semnalează până apare pe factura din luna următoare. Un workload care face streaming continuu de un gigabit de date către un partener depășește 30.000 de dolari pe lună, și echipa care a configurat integrarea adesea nu știe până când întreabă Finance.
Numărul de request-uri. S3 taxează per request: aproximativ jumătate de cent per mie de request-uri PUT și o douăzecime de cent per mie de request-uri GET. Un pipeline care scrie zece milioane de fișiere mici pe zi plătește pentru zece milioane de PUT-uri, și același pipeline citindu-le înapoi plătește din nou. Soluția (compactare de fișiere) e subiectul lecției 66, dar capcana de cost merită semnalată aici.
Ingestia de loguri. CloudWatch Logs taxează în jur de 50 de cenți per gigabyte ingerat. O aplicație configurată greșit care loghează fiecare corp de request la nivel DEBUG poate ingera sute de gigabytes pe zi, pentru mii de dolari pe lună, cu inginerul care a setat nivelul de log mutat de mult la altă echipă. Datadog, Splunk și alte platforme de log terțe au aceeași formă cu propriile lor tier-uri de prețuri.
Poveștile clasice cu facturi-surpriză
Fiecare echipă care a fost pe AWS de mai mult de un an are cel puțin una dintre aceste povești. Tiparele se repetă suficient cât să merite catalogate.
Logurile de acces S3 care s-au ingerat singure. O echipă a pornit logurile de acces S3 pentru un bucket de analiză și a configurat destinația ca același bucket. Fiecare acces genera o intrare de log, intrarea de log era un acces, accesul genera o intrare de log. Bucket-ul a crescut exponențial peste un weekend, și factura de storage de luni a fost cu un ordin sau două de mărime peste așteptări. Soluția e trivială (bucket de destinație separat, lifecycle policy pe bucket-ul de loguri). Lecția e că configurațiile recursive sunt ușor de pus în picioare și produc facturi neliniare.
Volumul EBS uitat. O echipă a terminat o instanță EC2 în timpul unui refactor dar a lăsat volumul EBS atașat ca storage detașat, cu flag-ul „delete on termination” setat la false. Volumul a continuat să taxeze la rata GB-lună timp de doi ani înainte ca cineva să observe într-un audit. Înmulțit pe flotă, volumele orfan netaggate sunt o linie permanentă în engagement-urile de optimizare a costurilor.
Egress-ul deschis care a făcut backfill cu un terabyte. O nouă integrare cu un partener s-a livrat într-o vineri. Integrarea a făcut backfill cu un terabyte de date istorice peste weekend printr-un NAT Gateway fără cap-uri și fără monitorizare. Factura de luni a arătat egress-ul și procesarea NAT pentru un singur weekend la în jur de 135 de dolari, plus egress-ul la în jur de 90 de dolari per terabyte. Repetă backfill-ul pentru zece parteneri și linia devine vizibilă suficient cât să întrebe Finance.
Cluster-ul Kafka peste trei AZ-uri. O echipă a configurat Kafka cu trei broker-i, unul per AZ, pentru disponibilitate înaltă. Producătorii și consumatorii erau în AZ-uri arbitrare. Fiecare produce, fiecare replicare, fiecare consume care trecea o limită de AZ costa trafic cross-AZ. După șase luni, linia cross-AZ pe workload-ul Kafka era mai mare decât linia EC2 pentru broker-ii înșiși. Soluția (rack-awareness, fixarea leadership-ului partițiilor, plasarea atentă a consumatorilor) e muncă de inginerie reală și trebuie proiectată de la început, nu adăugată ulterior.
Default-ul DEBUG de CloudWatch Logs. Un serviciu nou s-a livrat cu logging la nivel DEBUG în producție din greșeală. Ingestia CloudWatch Logs rula în jur de 50 de cenți per gigabyte, serviciul loga 200 GB pe zi, iar linia era 100 de dolari pe zi sau 3.000 de dolari pe lună. Serviciul a rulat așa două luni înainte ca un review al facturii să prindă. Remedierea e directă (strânge nivelurile de log, adaugă bugete de ingestie, alertează la cheltuiala de log per serviciu). Tiparul se repetă.
Tema comună: fiecare dintre acestea e invizibil pentru echipa care rulează workload-ul. Costul apare pe o factură pe care echipa nu o privește, într-o categorie pe care n-o deține, atribuit unui serviciu despre care nu și-a dat seama că are linia. Fără o structură care să aducă costurile înapoi la echipa care le-a cauzat, nimic nu se schimbă.
FinOps ca disciplină
FinOps e disciplina operațională care face din costul cloud o preocupare de prim rang alături de fiabilitate și performanță. FinOps Foundation (https://www.finops.org/, consultat 2026-05-01) e organismul industriei, și FinOps Framework documentează practicile pe care le adoptă o organizație matură. Termenul în sine datează din jurul lui 2017, cu Foundation formându-se în 2019 și ajungând la masă critică prin 2022 până în 2024.
Framework-ul se bazează pe trei faze care se buclează continuu.
Inform. Obține datele. Tag-uiește fiecare resursă cu o echipă, un produs și un mediu. Construiește dashboard-uri de cost care atribuie cheltuiala echipei care a cauzat-o. Fă factura vizibilă oamenilor care o pot schimba.
Optimise. Folosește datele. Right-size pentru compute (lecția 67), tier pentru storage (lecția 66), cumpără capacitate rezervată pentru baseline-urile predictibile, ucide resursele orfane, repară căile de egress. Lecțiile de optimizare ale Modulului 9 se potrivesc aici.
Operate. Continuă să folosești datele. Review-uri de cost pe o cadență regulată. Obiective de cost ca parte din OKR-urile echipei. Alerte de anomalie când o linie sare. FinOps devine parte din ritmul operațional, nu un proiect unic.
Specificația FOCUS (FinOps Open Cost and Usage Specification, https://focus.finops.org/, consultat 2026-05-01) e încercarea recentă de schemă vendor-neutră pentru date de facturare, ca o organizație multi-cloud să poată analiza costurile AWS, Azure și GCP într-o formă unificată. În 2026, FOCUS 1.0 e publicat și majoritatea cloud-urilor majore exportă date de facturare conforme FOCUS. Pentru o echipă care rulează pe un singur cloud, FOCUS e exagerat. Pentru o echipă care rulează pe două sau mai multe, e substratul care face analiza consolidată de cost tractabilă.
Dashboard-ul de care toată lumea are nevoie
Dashboard-ul pe care îl are o echipă matură de platformă de date, și pe care una în maturizare e în proces să-l construiască, descompune factura cloud pe trei axe.
Pe echipă. Cheltuiala cărei echipe a crescut luna asta? Care echipă e cea mai mare linie? Disciplina de tagging e ce face asta posibil: fiecare resursă poartă un tag team, tag-urile de alocare a costurilor sunt activate în consola de facturare, și dashboard-ul grupează după tag.
Pe produs. În cadrul unei echipe, în care produs sau serviciu e concentrată cheltuiala? Util pentru capacity planning, util pentru conversațiile de buget cu product managerii, util când un produs e retras și costul ar trebui să cadă brusc.
Pe mediu. Production, staging, development, sandbox. Constatarea clasică e că staging și development împreună costă 30 până la 50 la sută din production, și majoritatea sunt workload-uri lăsate să ruleze peste weekend-uri și peste noapte care n-aveau nevoie să fie. Auto-shutdown-ul mediilor non-production e una dintre intervențiile de cost cu cel mai mare ROI pe care o echipă o poate implementa.
Dashboard-ul nu trebuie să fie exotic. AWS Cost Explorer cu tag-urile de alocare a costurilor activate, câteva view-uri salvate și un review săptămânal în calendarul echipei acoperă majoritatea valorii. Uneltele de la vendori (CloudHealth, Apptio Cloudability, Vantage, Spot.io, ecosistemul de platforme FinOps) adaugă profunzime pentru organizațiile suficient de mari încât să justifice cheltuiala pe uneltele în sine, dar disciplina de bază e ce contează.
Unde merge restul modulului
Lecția aceasta a pregătit scena. Lecția 66 ia axa de storage și merge în adâncime: tiering peste S3 storage classes, lifecycle policies, capcana costurilor de retrieval Glacier, compactarea fișierelor pentru Parquet și funcționalitățile de optimizare automată din Iceberg și Delta. Lecția 67 ia axa de compute: instanțe Spot și preemptible, autoscaling făcut bine versus făcut prost, right-sizing ca disciplină regulată și capacitate rezervată pentru baseline-uri predictibile. Lecțiile ulterioare acoperă costul la nivel de query (optimizarea query-urilor de warehouse), tipare arhitecturale care se compun în timp (implicațiile de cost ale multi-region versus single-region, ale microserviciilor versus monoliților din punctul de vedere al costului de trafic), și întrebarea culturală despre cum face o echipă din cost o preocupare comună.
Firul roșu prin tot e cadrul aisbergului. Fiecare decizie de cost are o parte vizibilă pe care inginerul o optimizează și o parte ascunsă pe care factura o înregistrează. Echipa care citește factura, o atribuie înapoi la munca ce a cauzat-o, și tratează costul ca pe o preocupare reală alături de fiabilitate și performanță e echipa care va păstra platforma când vine sezonul de buget.
Citări și lecturi suplimentare
- Paginile de prețuri AWS,
https://aws.amazon.com/pricing/(consultat 2026-05-01). Referința canonică pentru prețurile de compute, storage și rețea menționate pe parcursul lecției. Sub-paginile specifice pentru VPC (https://aws.amazon.com/vpc/pricing/), S3 (https://aws.amazon.com/s3/pricing/) și EC2 (https://aws.amazon.com/ec2/pricing/) poartă cifrele per linie. - FinOps Foundation,
https://www.finops.org/(consultat 2026-05-01). Organismul industriei pentru managementul financiar al cloud-ului. Raportul anual State of FinOps are cifrele aproximative de compoziție citate mai sus. - FinOps Foundation, specificația FOCUS,
https://focus.finops.org/(consultat 2026-05-01). Schema vendor-neutră de facturare pentru analiza de cost multi-cloud. - Cloudflare, „AWS’s Egregious Egress”,
https://blog.cloudflare.com/aws-egregious-egress/(consultat 2026-05-01). Argumentul de ce prețul egress-ului e cea mai distorsionată linie pe o factură cloud tipică, și contextul pentru care object stores cu zero-egress au piață. - J. R. Storment și Mike Fuller, „Cloud FinOps”, O’Reilly, ediția a 2-a (2023). Cartea care a stabilit FinOps ca disciplină recunoscută; ediția a doua e textul de referință actual.