Il Modulo 8 si è chiuso con le pratiche operative che trasformano una data platform in qualcosa che un team riesce davvero a far girare. Il Modulo 9 si apre con il livello successivo di serietà: la piattaforma deve essere economicamente sostenibile. Una piattaforma affidabile che costa tre volte quello che il business si aspettava viene tagliata. Una piattaforma economica che perde dati costa al business molto più di quanto faccia risparmiare. Il costo non è l’opposto di affidabilità o performance; è il terzo asse che un team maturo deve bilanciare.
Questa lezione apre il modulo descrivendo la forma di una bolletta cloud. La conclusione principale, che ogni praticante FinOps ha interiorizzato e la maggior parte degli ingegneri no, è che il compute è solo la parte visibile. La bolletta vera è un iceberg, e la parte sotto la linea di galleggiamento è dove vivono le sorprese. Storage, network egress, NAT gateway, traffico cross-AZ, request count, log ingestion e una lunga coda di voci legate ai managed service compongono il grosso della bolletta nella maggior parte delle aziende mature.
L’inquadramento conta perché le leve a cui un ingegnere si rivolge per istinto sono leve di compute. Right-size dell’istanza EC2. Usa Spot. Scala giù di notte. Funzionano, e la lezione 67 le copre in dettaglio. Ma un team che si concentra solo sul compute risolverà un terzo del problema e scoprirà gli altri due terzi quando la bolletta di egress triplicherà dopo il rilascio di un’integrazione con un partner.
Che forma ha davvero la bolletta
I sondaggi pubblici, i report dei vendor e gli State of FinOps della FinOps Foundation convergono su una composizione di massima per una tipica azienda mid-size su AWS. Le percentuali esatte variano a seconda del workload, ma la forma è riconoscibile nella maggior parte delle organizzazioni data-heavy.
- Compute (EC2, nodi EKS, Fargate, Lambda, EMR): circa il 30 per cento.
- Storage (S3, EBS, EFS, snapshot, backup): circa il 20 per cento.
- Network (egress verso internet, data processing del NAT Gateway, traffico cross-AZ, trasferimento inter-region): circa il 15 per cento.
- Managed service (RDS, DynamoDB, Aurora, Redshift, Snowflake su AWS, Kinesis, MSK, OpenSearch): circa il 15 per cento.
- Voci adiacenti al data transfer (CloudFront, Direct Connect, Transit Gateway, VPC endpoint): circa il 10 per cento.
- Tutto il resto (security tooling, monitoring, SaaS di terze parti tramite Marketplace, istanze GPU per ML, KMS, Secrets Manager, varie ed eventuali): il restante 10 per cento.
I numeri dei report annuali della FinOps Foundation (https://www.finops.org/, consultato 2026-05-01) sono nello stesso intorno, con variazioni rilevanti per settore. Le aziende streaming-heavy vedono il network superare il compute. Le aziende analytics-heavy vedono dominare lo storage e la spesa per managed warehouse. Le aziende ML-heavy vedono il compute GPU e lo storage attached agli acceleratori prendersi una fetta più grande. Il report annuale di Cloudflare sui prezzi della banda (https://blog.cloudflare.com/aws-egregious-egress/, consultato 2026-05-01) sostiene la tesi che l’egress AWS in particolare sia prezzato un ordine di grandezza sopra il costo sottostante, ed è per questo che Cloudflare R2 e simili object store a egress zero hanno un mercato non trascurabile.
Il punto non sono le percentuali esatte, che si spostano nel tempo e tra team. Il punto è che il compute è grossomodo un terzo della bolletta, e il team che guarda solo il compute sta guardando il tabellone sbagliato.
L’iceberg
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 --> HiddenAlcune voci sotto la linea di galleggiamento meritano di essere chiamate per nome individualmente perché colgono i team di sorpresa più delle altre.
Data processing del NAT Gateway. Un NAT Gateway in AWS costa circa 4,5 centesimi per gigabyte processato, oltre alla tariffa oraria per gateway. Un workload che tira giù cento gigabyte al giorno da S3 attraverso un NAT Gateway, invece che attraverso un VPC endpoint, costa circa 135 dollari al mese solo per la fee di data processing, e questo per un singolo workload. Moltiplicato su una flotta, una configurazione di VPC endpoint mancante può aggiungere migliaia di dollari al mese per traffico che dovrebbe essere gratis. Le pagine pricing di AWS (https://aws.amazon.com/vpc/pricing/, consultato 2026-05-01) hanno i numeri canonici.
Traffico cross-AZ. AWS fa pagare grossomodo 1 centesimo per gigabyte in ciascuna direzione per il traffico tra availability zone della stessa region, per un round trip di 2 centesimi per gigabyte. Una mesh di microservizi chiacchierona distribuita su tre AZ può generare terabyte al giorno di chatter cross-AZ. Un team che fa girare Kafka con broker in tre AZ e consumer in tre AZ paga per ogni messaggio replicato e consumato che attraversa un confine di AZ. Producer e consumer topology-aware (rack-awareness in Kafka, zone-aware routing nelle service mesh) esistono proprio per tenere a bada questo costo.
Egress verso internet. Il traffico in uscita da AWS verso la internet pubblica gira attorno a 9 centesimi per gigabyte per il primo tier, scendendo con il volume ma non arrivando mai a zero. Un workload che fa il backfill di un terabyte verso un partner è una spesa una tantum di 90 dollari che nessuno segnala finché non spunta sulla bolletta del mese successivo. Un workload che fa streaming continuo di un gigabit di dati verso un partner viaggia oltre i 30.000 dollari al mese, e il team che ha messo su l’integrazione spesso non se ne accorge finché Finance non chiede spiegazioni.
Request count. S3 fa pagare per request: grossomodo mezzo centesimo per migliaio di PUT request e un ventesimo di centesimo per migliaio di GET request. Una pipeline che scrive dieci milioni di file minuscoli al giorno sta pagando per dieci milioni di PUT, e la stessa pipeline che li rilegge sta pagando di nuovo. La soluzione (file compaction) è il tema della lezione 66, ma vale la pena segnalare la trappola di costo già qui.
Log ingestion. CloudWatch Logs costa circa 50 centesimi per gigabyte ingerito. Un’applicazione mal configurata che logga ogni request body al livello DEBUG può ingerire centinaia di gigabyte al giorno, per migliaia di dollari al mese, con l’ingegnere che ha impostato il log level ormai da tempo passato a un altro team. Datadog, Splunk e altre piattaforme di log di terze parti hanno la stessa forma con i propri tier di pricing.
Le classiche storie da bolletta a sorpresa
Ogni team che è su AWS da più di un anno ha almeno una di queste storie. I pattern si ripetono abbastanza da meritare un catalogo.
I log di accesso S3 che ingerivano se stessi. Un team ha attivato i log di accesso S3 per un bucket di analytics e ha configurato come destinazione lo stesso bucket. Ogni accesso generava una entry di log, l’entry di log era un accesso, l’accesso generava una entry di log. Il bucket è cresciuto in modo esponenziale durante un weekend, e la bolletta dello storage del lunedì era un paio di ordini di grandezza sopra le aspettative. La soluzione è banale (bucket di destinazione separato, lifecycle policy sul bucket dei log). La lezione è che le configurazioni ricorsive sono facili da impostare e producono bollette non lineari.
Il volume EBS dimenticato. Un team ha terminato un’istanza EC2 durante un refactor ma ha lasciato il volume EBS attaccato come storage scollegato, con il flag “delete on termination” impostato a false. Il volume ha continuato a essere fatturato a tariffa GB-month per due anni prima che qualcuno se ne accorgesse durante un audit. Moltiplicati sulla flotta, i volumi orfani senza tag sono una voce perenne negli ingaggi di cost optimisation.
L’egress aperto che ha fatto il backfill di un terabyte. Una nuova integrazione partner è stata rilasciata di venerdì. L’integrazione ha fatto il backfill di un terabyte di dati storici durante il weekend attraverso un NAT Gateway senza cap e senza monitoring. La bolletta del lunedì mostrava l’egress e il NAT processing per un singolo weekend a circa 135 dollari, più l’egress a circa 90 dollari per terabyte. Ripeti il backfill per dieci partner e la voce diventa abbastanza visibile da far fare domande a Finance.
Il cluster Kafka su tre AZ. Un team ha messo su Kafka con tre broker, uno per AZ, per high availability. Producer e consumer erano in AZ arbitrarie. Ogni produce, ogni replica, ogni consume che attraversava un confine di AZ costava traffico cross-AZ. Dopo sei mesi, la voce cross-AZ sul workload Kafka era più grande della voce EC2 per i broker stessi. La soluzione (rack-awareness, partition leadership pinning, posizionamento attento dei consumer) è lavoro di ingegneria vero e va progettato dentro, non aggiunto dopo.
Il default DEBUG di CloudWatch Logs. Un nuovo servizio è stato rilasciato per errore con logging a livello DEBUG in produzione. L’ingestion di CloudWatch Logs viaggiava intorno a 50 centesimi per gigabyte, il servizio loggava 200 GB al giorno, e la voce era 100 dollari al giorno o 3.000 dollari al mese. Il servizio ha girato così per due mesi prima che una review della bolletta lo intercettasse. La rimedio è semplice (stringere i log level, aggiungere budget di ingestion, allertare sulla spesa di log per servizio). Il pattern si ripete.
Il tema condiviso: ognuno di questi è invisibile al team che fa girare il workload. Il costo spunta su una bolletta che il team non guarda, in una categoria di cui non è owner, attribuito a un servizio di cui non sapevano nemmeno che avesse quella voce. Senza una struttura per riportare i costi al team che li ha causati, niente cambia.
Il FinOps come disciplina
Il FinOps è la disciplina operativa che rende il costo del cloud una preoccupazione di prima classe accanto ad affidabilità e performance. La FinOps Foundation (https://www.finops.org/, consultato 2026-05-01) è l’ente di settore, e il FinOps Framework documenta le pratiche che un’organizzazione matura adotta. Il termine stesso risale al 2017 circa, con la Foundation costituita nel 2019 e arrivata a massa critica tra il 2022 e il 2024.
Il framework si appoggia su tre fasi che si ripetono in loop continuo.
Inform. Procurati i dati. Tagga ogni risorsa con team, prodotto e ambiente. Costruisci dashboard di costo che attribuiscono la spesa al team che l’ha causata. Rendi la bolletta visibile alle persone che possono cambiarla.
Optimise. Usa i dati. Right-size del compute (lezione 67), tiering dello storage (lezione 66), acquisto di reserved capacity per le baseline prevedibili, eliminazione delle risorse orfane, sistemazione dei percorsi di egress. Le lezioni di ottimizzazione del Modulo 9 si collocano qui.
Operate. Continua a usare i dati. Review dei costi a cadenza regolare. Obiettivi di costo come parte degli OKR del team. Anomaly alert quando una voce si impenna. Il FinOps diventa parte del ritmo operativo, non un progetto una tantum.
La specifica FOCUS (FinOps Open Cost and Usage Specification, https://focus.finops.org/, consultato 2026-05-01) è il tentativo recente di uno schema vendor-neutral per i dati di billing, in modo che un’organizzazione multi-cloud possa analizzare i costi di AWS, Azure e GCP in una forma unificata. Al 2026, FOCUS 1.0 è pubblicato e la maggior parte dei principali cloud esporta dati di billing conformi a FOCUS. Per un team che gira su un singolo cloud, FOCUS è eccessivo. Per un team che gira su due o più, è il substrato che rende trattabile l’analisi consolidata dei costi.
La dashboard di cui tutti hanno bisogno
La dashboard che un team data platform maturo ha, e che uno in maturazione sta costruendo, scompone la bolletta cloud lungo tre assi.
Per team. La spesa di quale team è cresciuta questo mese? Quale team è la voce più grande? La disciplina di tagging è ciò che rende possibile tutto questo: ogni risorsa porta un tag team, i cost-allocation tag sono abilitati nella billing console, e la dashboard raggruppa per tag.
Per prodotto. Dentro un team, in quale prodotto o servizio si concentra la spesa? Utile per il capacity planning, utile per le conversazioni sul budget con i product manager, utile quando un prodotto viene ritirato e il costo dovrebbe crollare a picco.
Per ambiente. Production, staging, development, sandbox. La scoperta classica è che staging e development insieme costano dal 30 al 50 per cento di production, e gran parte di questo sono workload lasciati in esecuzione nei weekend e di notte che non ne avevano bisogno. L’auto-shutdown degli ambienti non-production è uno degli interventi di costo a più alto ROI che un team possa implementare.
La dashboard non deve essere esotica. AWS Cost Explorer con i cost-allocation tag abilitati, un paio di view salvate, e una review settimanale sul calendario del team coprono la maggior parte del valore. Gli strumenti dei vendor (CloudHealth, Apptio Cloudability, Vantage, Spot.io, l’ecosistema di piattaforme FinOps) aggiungono profondità per le organizzazioni abbastanza grandi da giustificare la spesa sul tooling stesso, ma ciò che conta è la disciplina sottostante.
Dove va il resto del modulo
Questa lezione ha preparato il terreno. La lezione 66 prende l’asse storage e va in profondità: tiering tra le storage class di S3, lifecycle policy, la trappola dei costi di retrieval di Glacier, file compaction per Parquet e le funzionalità di ottimizzazione automatica in Iceberg e Delta. La lezione 67 prende l’asse compute: Spot e preemptible instance, autoscaling fatto bene contro fatto male, right-sizing come disciplina regolare, e reserved capacity per le baseline prevedibili. Le lezioni successive coprono il costo a livello di query (ottimizzazione delle query del warehouse), i pattern architetturali che si compongono nel tempo (le implicazioni di costo del multi-region contro single-region, dei microservizi contro i monoliti dal punto di vista del costo del traffico) e la questione culturale di come un team rende il costo una preoccupazione condivisa.
Il filo che attraversa tutto è l’inquadramento dell’iceberg. Ogni decisione di costo ha una parte visibile che l’ingegnere ottimizza e una parte nascosta che la bolletta registra. Il team che legge la bolletta, la attribuisce al lavoro che l’ha causata, e tratta il costo come una preoccupazione reale accanto ad affidabilità e performance è il team che si tiene la propria piattaforma quando arriva la stagione del budget.
Citazioni e letture di approfondimento
- Pagine pricing di AWS,
https://aws.amazon.com/pricing/(consultato 2026-05-01). Il riferimento canonico per il pricing di compute, storage e network citato in tutta la lezione. Sotto-pagine specifiche per VPC (https://aws.amazon.com/vpc/pricing/), S3 (https://aws.amazon.com/s3/pricing/) e EC2 (https://aws.amazon.com/ec2/pricing/) portano i numeri per singola voce. - FinOps Foundation,
https://www.finops.org/(consultato 2026-05-01). L’ente di settore per il cloud financial management. Il report annuale State of FinOps ha i numeri di composizione di massima citati sopra. - FinOps Foundation, specifica FOCUS,
https://focus.finops.org/(consultato 2026-05-01). Lo schema di billing vendor-neutral per l’analisi dei costi multi-cloud. - Cloudflare, “AWS’s Egregious Egress”,
https://blog.cloudflare.com/aws-egregious-egress/(consultato 2026-05-01). Il caso del perché il pricing dell’egress sia la voce più distorta su una tipica bolletta cloud, e il contesto del perché gli object store a egress zero abbiano un mercato. - J. R. Storment e Mike Fuller, “Cloud FinOps”, O’Reilly, 2a edizione (2023). Il libro che ha stabilito il FinOps come disciplina riconosciuta; la seconda edizione è il testo di riferimento attuale.