Compute e storage sono visibili su ogni dashboard. Il team può vedere quanti core stanno girando, quanti terabyte sono memorizzati e grossomodo quanto costa ciascuno. Nessuno è sorpreso dalla riga EC2 sulla bolletta, perché c’è qualcuno che la guarda. La riga che sorprende i team è quella etichettata “data transfer”, e li sorprende perché nessuno la guarda. Una pipeline che copia cento gigabyte tra region non spunta su un grafico di CPU. Un servizio che fa fan-out di mille piccole risposte tra availability zone non spunta su un grafico di memoria. Entrambi spuntano sulla fattura a fine mese, spesso come la singola voce più grande, e spesso solo dopo una email di Finance scritta nel panico.
Questa lezione parla di quella riga. La meccanica del pricing del network cloud, i pattern che producono bollette a sorpresa, le leve architetturali che riportano il numero sotto controllo. Il focus è AWS perché la sua struttura di pricing è la più documentata e la più copiata; GCP e Azure differiscono nei dettagli ma le forme sono le stesse.
Perché i costi di network si nascondono
Tre cose cospirano per rendere il costo del network invisibile fino all’arrivo della bolletta.
Primo, l’unità è piccola. Un gigabyte di egress a 0,09 dollari sono nove centesimi. Nove centesimi per gigabyte non sembrano una cosa che valga la pena pensarci. L’istinto è confrontarli con il costo orario di un’istanza (da 0,10 dollari a diversi dollari) e concludere che i byte sono rumore. L’errore è che i byte si accumulano alle velocità delle macchine. Un servizio che muove 1 Gbps in continuo muove 10,8 TB al giorno, che a 0,09 dollari per GB sono circa 970 dollari al giorno, ovvero 30K dollari al mese, per un solo servizio.
Secondo, il metering avviene a livelli di infrastruttura che il team applicativo non guarda. L’applicazione vede una HTTP response andata a buon fine. La bolletta vede un addebito per i byte che sono passati attraverso un NAT gateway, un VPC peer, un internet gateway o un link cross-region. La contabilità è corretta; è solo lontana dal posto dove il costo viene generato.
Terzo, i peggiori pattern sembrano identici a quelli economici dal punto di vista dell’applicazione. Un servizio che chiama un altro servizio allo stesso indirizzo IP è lo stesso percorso di codice sia che il target sia nella stessa availability zone (gratis o quasi gratis) sia che sia in una region diversa (costoso). La bolletta del network è dove conta la geografia, e la geografia è nascosta al codice.
Egress AWS: il numero in prima pagina
L’addebito di network più visibile è l’egress: il traffico che lascia AWS verso la internet pubblica. La pagina pricing di AWS (https://aws.amazon.com/ec2/pricing/on-demand/, consultato 2026-05-01) elenca tariffe a tier che dipendono da region e volume. Al 2026 la fascia tipica per le region Nord Americane ed Europee è attorno a 0,05-0,09 dollari per GB, con sconti che entrano in gioco alle soglie mensili di 10 TB e 50 TB e sconti più grandi negoziabili sopra i 500 TB.
L’aritmetica è impietosa una volta che il volume è grande. Un team che serve 1 TB al giorno di traffico pubblico paga grossomodo 80 dollari al giorno, che sono 2400 dollari al mese, che sono 29K dollari all’anno. Un team che serve 10 TB al giorno paga 290K dollari all’anno. Un team che serve 100 TB al mese (cosa non insolita per un’applicazione con una mobile app attiva o una API pubblica) paga circa 8K dollari al mese di solo egress.
Le horror story che circolano sui canali operativi condividono un pattern: nessuno sapeva il volume finché non è arrivata la bolletta. Un bucket S3 aperto è servito da CDN pubblica involontaria e ha accumulato decine di migliaia di dollari in un weekend. Una replica cross-region mal configurata ha fatto il backfill di terabyte multipli ogni notte. Un cron job ha scaricato un file da cento gigabyte ogni minuto perché qualcuno ha copia-incollato un one-liner da un vecchio runbook e ha tolto la cache. Ognuno di questi è un errore di configurazione; ognuno costa più di tutto il resto del compute del team messo insieme per il mese in cui ha girato non rilevato.
Cross-AZ: il moltiplicatore silenzioso
Il secondo tier di addebito è il traffico cross-availability-zone dentro una region. La tariffa è circa 0,01 dollari per GB per direzione nella maggior parte delle region AWS, a volte 0,02 dollari. Il numero sembra piccolo. Non lo è.
I deployment multi-AZ sono il pattern standard per la resilienza: metti l’applicazione su tre availability zone, metti il database su tre availability zone, fai girare il load balancer su tre. Il costo di quel pattern è che qualunque traffico tra applicazione e database, tra istanze applicative, tra applicazione e cache, ha una probabilità non trascurabile di attraversare un confine di AZ e incorrere nell’addebito per-GB per direzione.
Un servizio chiacchierone che muove 1 Gbps cross-AZ muove 86 TB al giorno. A 0,01 dollari per GB per direzione, sono circa 860 dollari al giorno per direzione, ovvero 20K dollari per direzione al mese. Un’architettura a microservizi in cui ogni chiamata interna ha una probabilità su tre di attraversare un’AZ produce costi di questa forma quasi ovunque. La bolletta li aggrega sotto una generica voce “regional data transfer” che non punta a nessun colpevole specifico.
La mitigazione architetturale è la località. Pinna le coppie di servizi chiacchierone alla stessa AZ dove il modello di resilienza lo permette. Usa load balancing AZ-aware in modo che un servizio in AZ-a preferisca un backend in AZ-a. Replica le letture di cache cross-AZ ma tieni le scritture di cache in-AZ. Il case study di Discord (lezione 32) e i post di replica di LinkedIn toccano entrambi questo tema; il pattern compare in quasi ogni case study pubblicato a scala.
NAT gateway: la tassa per-ora e per-GB
Il NAT gateway sta tra le subnet private e internet, traducendo il traffico in uscita in modo che le risorse private possano raggiungere servizi esterni senza essere indirizzabili pubblicamente. AWS lo prezza a circa 0,045 dollari l’ora più 0,045 dollari per GB di dati processati, per AZ.
Il solo addebito orario è 32 dollari al mese per gateway. I deployment multi-AZ con tre NAT gateway in esecuzione pagano 96 dollari al mese prima di qualunque traffico. Ambienti multipli (dev, staging, prod) moltiplicano la cifra. Un’organizzazione di medie dimensioni può spendere 1K dollari al mese in addebiti baseline di NAT gateway prima di processare un singolo byte.
L’addebito per-GB è quello che frega i team. Far passare il traffico verso servizi AWS (letture S3, query DynamoDB, fetch di secret) attraverso il NAT gateway significa pagare 0,045 dollari per GB sopra qualunque addebito del servizio. Una pipeline che legge un terabyte di dati S3 attraverso un NAT gateway paga 45 dollari di addebiti NAT per quella lettura, oltre ai costi di request e storage di S3. Moltiplica per il numero di esecuzioni di pipeline, il numero di ambienti e il numero di pipeline, e la voce diventa seria.
VPC endpoint: la soluzione standard
I VPC endpoint sono la risposta architetturale corretta al traffico verso servizi AWS che passa per il NAT. Forniscono un percorso privato dalla VPC verso specifici servizi AWS che non attraversa il NAT gateway e non conta come egress internet. Esistono due varianti:
Gateway endpoint: gratuiti, disponibili per S3 e DynamoDB. Non c’è scusa per non usarli. Una VPC che fa passare il traffico S3 senza un gateway endpoint sta pagando addebiti NAT che spariscono con un cambio di una riga nella route table.
Interface endpoint: addebitati per ora e per-GB processato ma tipicamente più economici del NAT, disponibili per la maggior parte degli altri servizi AWS (ECR, Secrets Manager, KMS, CloudWatch e molti altri). Pricing al 2026 è circa 0,01 dollari l’ora per AZ per endpoint, più circa 0,01 dollari per GB. L’aritmetica favorisce gli interface endpoint ogni volta che il volume passante per il NAT è più di qualche centinaio di GB al mese.
Il pattern di audit è semplice. Elenca i servizi AWS che le tue risorse private chiamano. Controlla se ognuno ha un endpoint disponibile. Confronta il costo dell’endpoint (orario + per-GB) con il costo NAT equivalente. Cambia quelli rumorosi. Il lavoro è per lo più impianto idraulico di route table e security group; i risparmi spuntano sulla bolletta successiva.
CDN: il risparmio controintuitivo
L’istinto “metti una CDN davanti al contenuto pubblico” è in parte performance (le risposte cached sono più vicine agli utenti) e in parte costo. La parte di costo è meno ovvia finché non si confrontano le tariffe.
L’egress diretto da S3 verso la internet pubblica gira al tier standard di 0,05-0,09 dollari per GB. La distribuzione di CloudFront da S3 verso le sue edge location costa come il traffico S3-verso-EC2 (molto più economico, spesso gratis per il percorso same-region), e l’egress di CloudFront verso gli end user gira a un tier diverso con sconti negoziati che scalano in modo aggressivo sopra i 10 TB. Per un asset pubblico ad alto volume (immagini, video, bundle JavaScript, file scaricabili), CloudFront è tipicamente 30-60 per cento più economico del serving S3 diretto una volta che il volume è significativo, e il cache-hit rate riduce ulteriormente il carico sull’origin.
Il pattern: qualunque bucket S3 che serve direttamente traffico pubblico a scala sta strapagando. Metti davanti una distribuzione CloudFront, punta il DNS a CloudFront, e la bolletta cala mentre la latenza migliora. Cloudflare e Fastly hanno economie simili. Il volume esatto di crossover dipende dalle tariffe negoziate, ma la direzione del risparmio è coerente e il cambio è meccanico.
L’egress come metrica primaria
Il filo che attraversa i pattern qui sopra è che l’egress è una metrica operativa di prima classe, allo stesso livello di CPU, memoria e request rate. Un team che lo tratta come una preoccupazione di Finance da guardare mensilmente è un team che scopre un problema molto dopo che è diventato costoso.
L’instrumentazione che fa la differenza:
- Dashboard di egress per servizio. VPC flow log, processati attraverso uno strumento che raggruppa il traffico per servizio sorgente, destinazione e coppia di AZ, e presenta una stima giornaliera della bolletta. La prima volta che un team vede questa dashboard, il peggior offender è di solito ovvio entro un minuto.
- Anomaly alert sulla bolletta. L’anomaly detection di Cost Explorer, o uno strumento di terze parti come Vantage o CloudHealth, allerta quando la spesa giornaliera devia dal trend. Una replica mal configurata o un cron impazzito triggera l’alert ore dopo l’inizio, non settimane.
- Budget di egress nel framework di SLO. Il concetto di error-budget della lezione 60 si applica qui: un servizio ha un “budget mensile di egress” allo stesso modo in cui ha un “budget mensile di downtime”. Sforare è un segnale che vale la pena investigare.
Diagramma da creare: una mappa di costo affiancata di due architetture. Il lato sinistro mostra un deployment naive: servizi in subnet private che fanno passare il traffico verso servizi AWS per un NAT gateway, chatter multi-AZ senza locality awareness, e un bucket S3 che serve direttamente traffico pubblico. Ogni percorso etichettato con una tariffa per-GB. Il lato destro mostra la versione ottimizzata: gateway endpoint per S3 e DynamoDB, interface endpoint per gli altri servizi AWS, load balancing AZ-aware e CloudFront davanti al bucket pubblico. Stessi percorsi, etichette per-GB molto più piccole.
Un’architettura target ragionevole
Per un team che costruisce o fa l’audit di un deployment nel 2026, i default cost-aware sono:
- Gateway endpoint per S3 e DynamoDB su ogni VPC. Gratis; risparmia addebiti NAT; dovrebbe essere nel modulo standard.
- Interface endpoint per ogni servizio AWS chiamato a volume rilevante dalle subnet private. Audit annuale man mano che nuovi servizi entrano in uso.
- Comunicazione service-to-service AZ-aware dove il modello di resilienza lo permette. Pinna le coppie chiacchierone alla stessa AZ.
- CloudFront (o CDN equivalente) davanti a qualunque bucket S3 che serve traffico pubblico sopra qualche centinaio di GB al mese.
- VPC flow log attivi, parsati in una dashboard di egress per servizio, riviste mensilmente come normale task del team di piattaforma.
- Cost-anomaly alert collegati al canale on-call della lezione 63, trattando uno spike di egress inatteso come un incidente che merita di essere paginato se la magnitudine lo giustifica.
L’effetto cumulativo di questi è grande. Un team che fa l’audit dei suoi pattern di NAT e AZ e migra agli endpoint taglia tipicamente la bolletta di network del 40-70 per cento senza cambiare niente di visibile all’utente. Il lavoro non è glamour e i risparmi ricorrono ogni mese finché l’architettura resta. È il tipo di cambiamento che ripaga lo stipendio dell’ingegnere diverse volte e non vince mai un premio dell’architecture-review-board.
Cosa preparano le prossime due lezioni
Questa lezione ha coperto l’angolo di costo dell’architettura di network. La lezione 69 prende l’angolo di scaling: quando il carico cresce dieci volte, quali di questi pattern sopravvivono e quali diventano colli di bottiglia? La lezione 70 prende l’angolo di latenza, con il caching come leva principale. Le tre insieme formano il triangolo costo-performance a cui il Modulo 9 continua a tornare: ogni scelta architetturale ha implicazioni sulla bolletta, sul soffitto di throughput e sul tempo di risposta, e il lavoro del team di piattaforma è tenere tutti e tre in vista.
Citazioni e letture di approfondimento
- AWS, “EC2 On-Demand Pricing”,
https://aws.amazon.com/ec2/pricing/on-demand/(consultato 2026-05-01). La sezione data-transfer è la fonte canonica per le tariffe di egress e cross-AZ citate in questa lezione. - AWS, “VPC Pricing”,
https://aws.amazon.com/vpc/pricing/(consultato 2026-05-01). Tariffe di NAT gateway e interface endpoint. - AWS, “Amazon CloudFront Pricing”,
https://aws.amazon.com/cloudfront/pricing/(consultato 2026-05-01). I tier di CDN e le tariffe per region che guidano il confronto CloudFront-contro-S3. - Cloudflare, serie “AWS’s Egregious Egress” sul blog di Cloudflare,
https://blog.cloudflare.com/aws-egregious-egress/(consultato 2026-05-01). Una scomposizione vendor-perspective ma ben documentata di come il pricing di egress di AWS si confronti con le alternative, utile per il quadro macro. - Google Cloud, “Network pricing”,
https://cloud.google.com/vpc/network-pricing(consultato 2026-05-01). Per confronto; la struttura ricalca AWS. - Microsoft Azure, “Bandwidth pricing”,
https://azure.microsoft.com/en-us/pricing/details/bandwidth/(consultato 2026-05-01). Per confronto; di nuovo, struttura simile. - Newsletter “Last Week in AWS” di Corey Quinn,
https://www.lastweekinaws.com/(consultato 2026-05-01). Commento di lunga data sulle sorprese di billing AWS, comprese molte delle storie di bolletta-egress che circolano nella community.