Compute-ul și storage-ul sunt vizibile pe orice dashboard. Echipa poate vedea câte core-uri rulează, câți terabytes sunt stocați și aproximativ cât costă fiecare. Nimeni nu e surprins de linia EC2 de pe factură, pentru că cineva o urmărește. Linia care surprinde echipele e cea etichetată „data transfer” și le surprinde pentru că nimeni n-o urmărește. Un pipeline care copiază o sută de gigabytes între regiuni nu apare pe un grafic de CPU. Un serviciu care face fan-out la o mie de răspunsuri mici peste availability zones nu apare pe un grafic de memorie. Amândouă apar pe factura de la sfârșitul lunii, adesea ca cel mai mare item individual și adesea doar după un email panicat de la finance.
Lecția aceasta e despre acea linie. Mecanica pricing-ului de rețea în cloud, pattern-urile care produc facturi surpriză, pârghiile arhitecturale care aduc numărul sub control. Focus-ul e pe AWS pentru că structura sa de pricing e cea mai bine documentată și cea mai copiată; GCP și Azure diferă în detaliu, dar formele sunt aceleași.
De ce se ascund costurile de rețea
Trei lucruri conspiră să facă costul de rețea invizibil până când sosește factura.
În primul rând, unitatea e mică. Un gigabyte de egress la 0,09$ înseamnă nouă cenți. Nouă cenți per gigabyte nu pare un lucru la care merită să te gândești. Instinctul e să-l compari cu costul per oră al unei instanțe (de la 0,10$ la câțiva dolari) și să concluzionezi că bytes sunt zgomot. Eroarea e că bytes se acumulează la viteze de mașină. Un serviciu care mută 1 Gbps continuu mută 10,8 TB pe zi, ceea ce la 0,09$ per GB înseamnă în jur de 970$ pe zi, sau 30K$ pe lună, pentru un singur serviciu.
În al doilea rând, măsurarea se întâmplă la straturi de infrastructură la care echipa de aplicație nu se uită. Aplicația vede un răspuns HTTP de succes. Factura vede o taxă pentru bytes care au curs printr-un NAT gateway, un VPC peer, un internet gateway sau o legătură cross-region. Contabilitatea e corectă; e doar departe de locul unde se generează costul.
În al treilea rând, cele mai proaste pattern-uri arată identic cu cele ieftine din punctul de vedere al aplicației. Un serviciu care apelează alt serviciu la aceeași adresă IP e același code path indiferent dacă target-ul e în aceeași availability zone (gratuit sau aproape gratuit) sau într-o regiune diferită (scump). Factura de rețea e locul unde geografia contează, iar geografia e ascunsă față de cod.
AWS egress: numărul de pe prima pagină
Cea mai proeminentă taxă de rețea e egress-ul: traficul care pleacă din AWS spre internetul public. Pagina de pricing AWS (https://aws.amazon.com/ec2/pricing/on-demand/, consultat 2026-05-01) listează rate pe trepte care depind de regiune și volum. Începând cu 2026, intervalul tipic pentru regiunile nord-americane și europene e în jur de 0,05$ până la 0,09$ per GB, cu discount-uri care intră la pragurile lunare de 10 TB și 50 TB și discount-uri mai mari negociabile peste 500 TB.
Aritmetica e neiertătoare odată ce volumul devine mare. O echipă care servește 1 TB pe zi de trafic public plătește în jur de 80$ pe zi, ceea ce înseamnă 2400$ pe lună, ceea ce înseamnă 29K$ pe an. O echipă care servește 10 TB pe zi plătește 290K$ pe an. O echipă care servește 100 TB pe lună (ceea ce nu e neobișnuit pentru o aplicație cu un mobile app activ sau un API public) plătește în jur de 8K$ pe lună doar pentru egress.
Poveștile de groază care circulă pe canalele de operațiuni au un pattern comun: nimeni n-a știut volumul până când a venit factura. Un bucket S3 deschis a servit ca un CDN public neintenționat și a adunat zeci de mii de dolari într-un weekend. O replicare cross-region prost configurată a făcut backfill la mai mulți terabytes peste noapte. Un job cron a descărcat un fișier de o sută de gigabytes în fiecare minut pentru că cineva a copiat un one-liner dintr-un runbook vechi și a scos cache-ul. Fiecare e o greșeală de configurare; fiecare costă mai mult decât tot restul compute-ului echipei combinat pentru luna în care a rulat nedetectată.
Cross-AZ: multiplicatorul tăcut
A doua treaptă de taxă e traficul cross-availability-zone în interiorul unei regiuni. Rata e în jur de 0,01$ per GB per direcție în majoritatea regiunilor AWS, uneori 0,02$. Numărul pare mic. Nu e.
Deployment-urile multi-AZ sunt pattern-ul standard pentru reziliență: pune aplicația în trei availability zones, pune baza de date în trei availability zones, rulează load balancer-ul peste trei. Costul acelui pattern e că orice trafic între aplicație și bază de date, între instanțe de aplicație, între aplicație și cache are o șansă semnificativă să traverseze o frontieră AZ și să suporte taxa per GB per direcție.
Un serviciu vorbăreț care mută 1 Gbps cross-AZ mută 86 TB pe zi. La 0,01$ per GB per direcție, asta înseamnă în jur de 860$ pe zi per direcție, sau 20K$ per direcție pe lună. O arhitectură de microservicii în care fiecare apel intern are o șansă de unu la trei să traverseze o AZ produce costuri de această formă aproape peste tot. Factura le agregă sub o linie generică „regional data transfer” care nu indică niciun infractor anume.
Mitigarea arhitecturală e localitatea. Pin pairs vorbărețe de servicii la aceeași AZ acolo unde modelul de reziliență permite. Folosește load balancing AZ-aware ca un serviciu din AZ-a să prefere un backend din AZ-a. Replică citirile de cache cross-AZ, dar ține scrierile de cache in-AZ. Studiul de caz Discord (lecția 32) și posturile de replicare LinkedIn ating amândouă acest lucru; pattern-ul apare în aproape orice studiu de caz publicat la scară.
NAT gateway: taxa per oră și per GB
NAT gateway-ul stă între subnets private și internet, traducând traficul outbound astfel încât resursele private să poată ajunge la servicii externe fără să fie adresabile public. AWS îl prețuiește la în jur de 0,045$ pe oră plus 0,045$ per GB de date procesate, per AZ.
Doar taxa orară înseamnă 32$ pe lună per gateway. Deployment-urile multi-AZ care rulează trei NAT gateways plătesc 96$ pe lună înainte de orice trafic. Mediile multiple (dev, staging, prod) multiplică asta. O organizație de mărime medie poate cheltui 1K$ pe lună pe taxe de bază pentru NAT gateway înainte de a procesa un singur byte.
Taxa per GB e cea care prinde echipele. Rutarea traficului către servicii AWS (citiri S3, query-uri DynamoDB, fetch-uri de secrets) prin NAT gateway înseamnă să plătești 0,045$ per GB peste orice taxă de serviciu. Un pipeline care citește un terabyte de date S3 prin NAT gateway plătește 45$ în taxe NAT pentru acea citire, peste costurile de cerere și storage S3. Înmulțește cu numărul de rulări de pipeline, numărul de medii și numărul de pipeline-uri și linia devine serioasă.
VPC endpoints: soluția standard
VPC endpoints sunt răspunsul arhitectural corect pentru traficul către servicii AWS rutat prin NAT. Oferă un drum privat de la VPC la servicii AWS specifice care nu trece prin NAT gateway și nu se contabilizează ca egress de internet. Există două variante:
Gateway endpoints: gratuite, disponibile pentru S3 și DynamoDB. Nu există scuză pentru a nu le folosi. Un VPC care rutează trafic S3 fără un gateway endpoint plătește taxe NAT care dispar cu o schimbare de o linie în route table.
Interface endpoints: taxate per oră și per GB procesat, dar de obicei mai ieftine decât NAT, disponibile pentru majoritatea celorlalte servicii AWS (ECR, Secrets Manager, KMS, CloudWatch și multe altele). Pricing-ul în 2026 e în jur de 0,01$ pe oră per AZ per endpoint, plus în jur de 0,01$ per GB. Aritmetica favorizează interface endpoints oricând volumul rutat prin NAT depășește câteva sute de GB pe lună.
Pattern-ul de audit e direct. Listează serviciile AWS pe care le apelează resursele tale private. Verifică dacă fiecare are un endpoint disponibil. Compară costul de endpoint (orar + per GB) cu costul echivalent NAT. Schimbă-le pe cele zgomotoase. Munca e în mare parte plumbing pe route-table și security-group; economiile apar pe următoarea factură.
CDN: economia contraintuitivă
Instinctul „pune un CDN în fața conținutului public” e parțial performanță (răspunsurile cached sunt mai aproape de utilizatori) și parțial cost. Partea de cost e mai puțin evidentă până când ratele sunt comparate.
Egress-ul direct S3 spre internetul public rulează la treapta standard de 0,05$ până la 0,09$ per GB. Distribuția CloudFront de la S3 către locațiile sale edge costă la fel ca traficul S3-către-EC2 (mult mai ieftin, adesea gratuit pentru același drum în-regiune), iar egress-ul CloudFront către utilizatorii finali rulează la o treaptă diferită cu discount-uri negociate care scalează agresiv peste 10 TB. Pentru un activ public cu volum mare (imagini, video-uri, bundle-uri JavaScript, fișiere descărcabile), CloudFront e tipic cu 30 până la 60 la sută mai ieftin decât servirea directă din S3 odată ce volumul e semnificativ, iar rata de cache-hit reduce și mai mult încărcarea pe origin.
Pattern-ul: orice bucket S3 care servește direct trafic public la scară plătește prea mult. Pune o distribuție CloudFront în față, îndreaptă DNS-ul către CloudFront și factura scade în timp ce latența se îmbunătățește. Cloudflare și Fastly au economie similară. Volumul exact de crossover depinde de ratele negociate, dar direcția economiei e consistentă, iar schimbarea e mecanică.
Egress ca metrică principală
Firul care trece prin pattern-urile de mai sus e că egress-ul e o metrică operațională de prim rang, la același nivel cu CPU, memoria și request rate. O echipă care îl tratează ca pe o preocupare de finance la care se uită lunar e o echipă care află de o problemă mult după ce a devenit costisitoare.
Instrumentația care face diferența:
- Dashboard-uri de egress per serviciu. VPC flow logs, procesate printr-un tool care grupează traficul după serviciul sursă, destinație și pereche AZ și prezintă o estimare zilnică a facturii. Prima oară când o echipă vede acest dashboard, cel mai mare infractor e de obicei evident într-un minut.
- Anomaly alerts pe factură. Detecția de anomalie a Cost Explorer sau un tool terț precum Vantage sau CloudHealth alertează când cheltuiala zilnică deviază de la trend. O replicare prost configurată sau un cron scăpat de sub control declanșează alerta la ore după ce începe, nu săptămâni.
- Bugete de egress în cadrul SLO. Conceptul de error-budget din lecția 60 se aplică aici: un serviciu are un „buget lunar de egress” în același fel în care are un „buget lunar de downtime”. Depășirea e un semnal care merită investigat.
Diagram to create: a side-by-side cost map of two architectures. The left side shows a naive deployment: services in private subnets routing AWS-service traffic through a NAT gateway, multi-AZ chatter without locality awareness, and an S3 bucket serving public traffic directly. Each path is labelled with a per-GB rate. The right side shows the optimised version: gateway endpoints for S3 and DynamoDB, interface endpoints for the other AWS services, AZ-aware load balancing, and CloudFront in front of the public bucket. Same paths, much smaller per-GB labels.
O arhitectură țintă rezonabilă
Pentru o echipă care construiește sau auditează un deployment în 2026, default-urile conștiente de cost sunt:
- Gateway endpoints pentru S3 și DynamoDB pe fiecare VPC. Gratuit; salvează taxe NAT; ar trebui să fie în modulul standard.
- Interface endpoints pentru orice serviciu AWS apelat la volum semnificativ din subnets private. Audit anual pe măsură ce intră servicii noi în uz.
- Comunicare service-to-service AZ-aware acolo unde modelul de reziliență permite. Pin pairs vorbărețe la aceeași AZ.
- CloudFront (sau CDN echivalent) în fața oricărui bucket S3 care servește trafic public peste câteva sute de GB pe lună.
- VPC flow logs activate, parsate într-un dashboard de egress per serviciu, revizuite lunar ca task normal al echipei de platformă.
- Cost-anomaly alerts cablate în canalul de on-call din lecția 63, tratând un spike de egress neașteptat ca pe un incident care merită paged dacă magnitudinea o cere.
Efectul de compunere al acestora e mare. O echipă care își auditează pattern-urile NAT și AZ și migrează la endpoints reduce tipic factura de rețea cu 40 până la 70 la sută fără să schimbe nimic vizibil utilizatorului. Munca e neglamoroasă, iar economiile recurente lună de lună atâta timp cât arhitectura rămâne. E genul de schimbare care plătește salariul inginerului de mai multe ori și nu câștigă niciodată un premiu de la architecture-review board.
Ce pregătesc următoarele două lecții
Lecția aceasta a acoperit unghiul de cost al arhitecturii de rețea. Lecția 69 ia unghiul de scaling: când încărcarea crește de zece ori, care dintre aceste pattern-uri supraviețuiesc și care devin bottleneck-uri? Lecția 70 ia unghiul de latență, cu caching ca pârghie principală. Cele trei împreună formează triunghiul cost-performanță la care Modulul 9 revine: fiecare alegere arhitecturală are implicații pe factură, pe plafonul de throughput și pe timpul de răspuns, iar treaba echipei de platformă e să țină toate trei în vizor.
Citări și lectură suplimentară
- AWS, „EC2 On-Demand Pricing”,
https://aws.amazon.com/ec2/pricing/on-demand/(consultat 2026-05-01). Secțiunea de data-transfer e sursa canonică pentru ratele de egress și cross-AZ referențiate în această lecție. - AWS, „VPC Pricing”,
https://aws.amazon.com/vpc/pricing/(consultat 2026-05-01). Ratele pentru NAT gateway și interface endpoints. - AWS, „Amazon CloudFront Pricing”,
https://aws.amazon.com/cloudfront/pricing/(consultat 2026-05-01). Treptele CDN și ratele per regiune care driveează comparația CloudFront-versus-S3. - Cloudflare, seria „AWS’s Egregious Egress” pe blogul Cloudflare,
https://blog.cloudflare.com/aws-egregious-egress/(consultat 2026-05-01). O perspectivă de vendor, dar bine documentată asupra modului în care pricing-ul de egress al AWS se compară cu alternativele, utilă pentru imaginea macro. - Google Cloud, „Network pricing”,
https://cloud.google.com/vpc/network-pricing(consultat 2026-05-01). Pentru comparație; structura paralelizează AWS. - Microsoft Azure, „Bandwidth pricing”,
https://azure.microsoft.com/en-us/pricing/details/bandwidth/(consultat 2026-05-01). Pentru comparație; din nou, structură similară. - Newsletter-ul „Last Week in AWS” al lui Corey Quinn,
https://www.lastweekinaws.com/(consultat 2026-05-01). Comentariu de lungă durată despre surprizele de billing AWS, inclusiv multe dintre poveștile cu factură de egress care circulă în comunitate.