La bolletta che nessuno aveva previsto

È successo a quasi tutti. Un lunedì mattina, una notifica di AWS o Azure con un importo che non torna. Qualcuno apre la console, inizia a cercare, trova un'istanza dimenticata, un bucket S3 con terabyte di log mai cancellati, un ambiente di test che gira da otto mesi in produzione per errore.

La reazione istintiva è spegnere tutto e cercare il colpevole. Ma il problema non è quell'istanza. È che nessuno stava guardando. FinOps: come tenere sotto controllo i costi cloud

Il cloud ha rotto qualcosa

Prima del cloud, la spesa IT era prevedibile. Compravi un server, sapevi quanto costava, lo ammortizzavi in cinque anni. Era capex — un impegno ponderato, approvato dal CFO, visibile in bilancio.

Il cloud ha trasformato quella spesa in opex variabile. Ogni decisione tecnica è diventata una decisione finanziaria: scegliere un'istanza più grande, abilitare un servizio, dimenticare di spegnere un ambiente. Il problema è che quasi nessuno in azienda lo sa — o almeno, non lo sente come proprio.

Gli sviluppatori pensano alla performance. I DevOps pensano alla stabilità. Il CFO vede solo una riga di costo che cresce ogni mese senza capire perché. FinOps è la risposta a questa rottura: non uno strumento, ma un modello operativo che assegna responsabilità chiare sulla spesa cloud.

Cosa significa FinOps in concreto

La FinOps Foundation — il consorzio che ha formalizzato la disciplina — definisce FinOps come la pratica che porta insieme finance, tecnologia e business per ottimizzare il valore del cloud. È una definizione corretta ma inutile.

In concreto significa tre cose:

  • Visibilità: sapere in tempo reale quanto stai spendendo, su cosa, e perché. Non a fine mese quando la fattura è già arrivata.
  • Responsabilità distribuita: ogni team che usa risorse cloud è responsabile del costo di quelle risorse. Non solo l'IT, non solo il finance.
  • Ottimizzazione continua: non un progetto una-tantum di cost cutting, ma un processo ricorrente di revisione e aggiustamento.
Il cambiamento più difficile non è tecnico. È culturale: convincere gli sviluppatori che il costo è una metrica di prodotto come la latenza o la disponibilità.

I tre errori che fanno lievitare la bolletta

Risorse dimenticate. È il più comune e il più evitabile. Ambienti di test creati per un progetto e mai dismessi, snapshot EBS accumulati per anni, load balancer senza traffico, indirizzi IP elastici non associati a nulla. In un'infrastruttura che esiste da qualche anno, il cloud waste — la spesa per risorse inutilizzate — si aggira tipicamente tra il 20% e il 35% della bolletta totale. Non è un'esagerazione: è il dato medio che emerge dai principali report di settore anno dopo anno.

Sizing sbagliato. L'istanza più grande sembra sempre la scelta sicura in fase di provisioning. In produzione, il 60-70% delle istanze cloud è cronicamente sottoutilizzato — CPU media sotto il 20%, memoria usata per metà. Rightsizing — ridimensionare le istanze al carico reale — è quasi sempre la leva con il miglior rapporto impatto/effort.

Egress ignorato. Il traffico in uscita dal cloud costa. Non tanto per il trasferimento tra servizi dello stesso provider nella stessa region, ma moltissimo per il traffico verso internet e tra region diverse. Un'architettura che muove grandi volumi di dati senza considerare l'egress può produrre sorprese significative in fattura. È uno dei motivi per cui la scelta dell'architettura dei dati va fatta prima della migrazione, non dopo.

Gli strumenti che hai già

Non serve comprare nulla. I tre principali provider hanno strumenti di cost management inclusi:

  • AWS Cost Explorer: visualizzazione della spesa per servizio, per tag, per account. Anomaly Detection avvisa quando la spesa devia dal pattern storico. Savings Plans e Reserved Instances per impegni a lungo termine con sconti significativi.
  • Azure Cost Management + Billing: stesso approccio, con integrazione nativa con i budget di Azure e alert configurabili per soglie di spesa.
  • Google Cloud Billing: report dettagliati, budget alert, e raccomandazioni automatiche di rightsizing basate sull'utilizzo reale.
Il problema non è la mancanza di strumenti — è che questi strumenti spesso non vengono configurati, o vengono configurati una volta e poi ignorati.

Il processo minimo che funziona

FinOps non richiede un team dedicato. Richiede un processo ricorrente con responsabilità chiare.

Il minimo funzionante per una PMI è:

  • Tagging sistematico: ogni risorsa cloud ha tag che identificano il progetto, il team, e l'ambiente (prod/staging/dev). Senza tagging, non puoi attribuire i costi a nessuno.
  • Budget alert: soglie di spesa configurate per account o per progetto, con notifiche via email quando si avvicina o supera il limite. Non per bloccare nulla — per sapere.
  • Revisione mensile: trenta minuti al mese per rivedere la spesa del mese precedente, identificare anomalie, e schedulare la dismissione delle risorse inutilizzate.
  • Checklist di offboarding: quando un progetto finisce o un ambiente non serve più, una procedura che include esplicitamente la dismissione delle risorse cloud associate.
Non è un sistema sofisticato. È sufficiente per evitare il 90% dei problemi che portano alle bollette sorpresa.

FinOps non serve a spendere meno

Il punto finale è quello che molti fraintendono. FinOps non è un esercizio di cost cutting. Non significa necessariamente ridurre la spesa cloud.

Significa spendere in modo consapevole. Significa che quando la bolletta cresce, sai perché cresce e puoi decidere se quella crescita è giustificata dal valore che produce. Significa che il CFO e il CTO parlano la stessa lingua quando discutono di infrastruttura.

Un'azienda che spende 50.000 euro all'anno in cloud sapendo esattamente dove va ogni euro è in una posizione molto migliore di una che spende 30.000 senza saperlo. Il risparmio non è l'obiettivo. La visibilità sì.