In sintesi: la maggior parte dei team FinOps monitora troppe metriche e agisce su troppo poche. Le metriche che contano rientrano in quattro categorie: finanziarie (scostamento dal budget, accuratezza delle previsioni), operative (utilizzo, copertura dei commitments, potenziale di right-sizing), spreco (risorse inattive, storage orfano, spesa non allocata) e di business (unit economics, costo in percentuale sui ricavi). Quali privilegiare dipende dallo stadio di maturità. Un team in fase crawl ha bisogno di metriche di visibilità. Un team in fase run ha bisogno di unit economics. E, a prescindere dallo stadio, una metrica priva di un livello di azione sottostante resta soltanto una dashboard.
Ai team FinOps non mancano di certo i dati sui costi cloud. AWS Cost Explorer, Google Cloud Billing, Azure Cost Management, piattaforme di terze parti: i dati ci sono. Molto più difficile è distinguere il segnale dal rumore, ovvero individuare i numeri che indicano dove si accumula lo spreco, se il lavoro di ottimizzazione sta dando frutti e se la spesa cloud cresce più o meno velocemente del business che sostiene.
È proprio in questo scarto tra dati e segnale che la maggior parte dei framework di metriche va in crisi. I team costruiscono dashboard con 40 KPI, tengono revisioni mensili che degenerano in archeologia dei costi e faticano a spiegare ai lead di engineering quale numero dovrebbero davvero tenere d'occhio nello sprint in corso. Secondo Gartner, solo il 43% delle organizzazioni monitora i costi cloud a livello di unità: significa che la maggior parte dei team non è in grado di collegare la bolletta cloud ai prodotti e ai clienti che la generano.
Questo articolo non vuole essere un elenco esaustivo di tutte le metriche di costo cloud. È un framework per decidere quali meritano la sua attenzione in ciascuno stadio di maturità FinOps, quali azioni ogni metrica dovrebbe innescare e in che modo gli errori di monitoraggio più diffusi portano i team fuori strada.
Cosa sono le metriche di cloud cost optimization e perché i team FinOps hanno bisogno di un framework?
Le metriche di cloud cost optimization sono segnali quantitativi che collegano i comportamenti di spesa cloud ai risultati di business. Aiutano i team FinOps a individuare gli sprechi, a verificare che il lavoro di ottimizzazione stia producendo risparmi reali e a prevedere la spesa futura con un'accuratezza sufficiente a supportare le decisioni di pianificazione.
La definizione è semplice. L'applicazione no. La sfida sta nello scegliere quelle giuste per la domanda che il suo business si sta ponendo in questo momento.
Monitorare troppe metriche produce lo stesso risultato di non monitorarne nessuna. Quando ogni numero ha lo stesso peso, nulla viene messo in priorità. Le revisioni diventano retrospettive, non azionabili. Gli engineer si disinteressano perché il rapporto segnale-rumore è troppo basso per giustificare l'attenzione.
Un approccio a livelli risolve il problema. Al posto di un elenco piatto di 30 KPI, un framework a livelli organizza le metriche per categoria e stadio di maturità. Ogni livello risponde a una domanda diversa: la nostra spesa è chiaramente visibile? Stiamo usando le risorse in modo efficiente? Stiamo eliminando gli sprechi? La spesa cloud cresce in proporzione al valore che genera?
Il modello crawl/walk/run della FinOps Foundation si sposa naturalmente con questa struttura. I team in fase iniziale hanno bisogno di metriche di visibilità, quelli in fase intermedia di metriche di ottimizzazione, quelli maturi di metriche di efficienza e valore di business. Bruciare le tappe non accelera i risultati: aggiunge solo complessità di reporting senza la qualità del dato necessaria a sostenerla.
Quali categorie di metriche di cloud cost optimization guidano i risultati FinOps?
Quattro categorie di metriche coprono l'intero spettro decisionale del FinOps: metriche finanziarie, che monitorano lo stato di salute di budget e forecast; metriche operative, che misurano l'efficienza con cui le risorse funzionano; metriche di spreco, che portano in superficie la spesa inattiva e orfana; metriche di business, che collegano i costi cloud al valore prodotto dall'azienda. Ogni categoria risponde a una domanda diversa e deve innescare azioni diverse.
Metriche finanziarie: scostamento dal budget e accuratezza del forecast
Lo scostamento dal budget misura la differenza percentuale tra spesa cloud pianificata ed effettiva. È la metrica finanziaria più diffusa nel cloud cost management ed è anche quella più spesso interpretata male.
Uno scostamento negativo (spesa inferiore al budget) sembra positivo su una dashboard, ma può nascondere sottoutilizzo o progetti in ritardo. Uno scostamento positivo (sforamento) merita di essere approfondito solo se si è in grado di distinguere la crescita organica dallo spreco vero e proprio. I team che considerano ogni scostamento positivo come un problema finiranno per fissare budget troppo conservativi, mettendo in difficoltà proprio i team di engineering che dovrebbero sostenere.
L'accuratezza del forecast misura quanto la spesa prevista corrisponde a quella effettiva al termine di un periodo di fatturazione. I benchmark di settore considerano accettabile una variazione del 10-15% per la maggior parte delle organizzazioni, mentre i team con strategie di commitment mature e workloads stabili spesso arrivano al 5% o meglio. La metrica è importante perché forecast imprecisi generano problemi a valle: i team finance inseriscono margini di sicurezza nei budget tech, i team di engineering ricevono alert di spesa a metà sprint e la leadership perde fiducia nel FinOps come funzione di pianificazione.
Entrambe le metriche migliorano grazie allo stesso investimento sottostante: allocazione dei costi pulita, tagging applicato con rigore e visibilità a livello di account che consenta di individuare le anomalie prima che si trasformino in scostamenti significativi.
Metriche operative: utilizzo, copertura dei commitments e potenziale di right-sizing
Le metriche di utilizzo misurano quanta parte di una risorsa provisionata i workloads consumano effettivamente. L'utilizzo di CPU e memoria sulle istanze di compute sono gli esempi più familiari e la soglia standard per i candidati al right-sizing varia in base al tipo di workload. La maggior parte dei team segnala come da rivedere le istanze con un utilizzo medio di CPU inferiore al 20-30%, sebbene i workloads sensibili alla latenza possano giustificare un provisioning più elevato per garantire margine.
L'utilizzo, da solo, è un segnale incompleto. Un cluster al 15% di utilizzo CPU potrebbe essere sovradimensionato oppure correttamente dimensionato per un workload che tocca il 90% nei picchi di carico. Le metriche di utilizzo indicano solo dove guardare. Non dicono se la risorsa è dimensionata correttamente finché non si osservano insieme picchi, medie e percentili.
La copertura dei commitments monitora la percentuale di workloads idonei coperti da reserved instances, Savings Plans o committed use discounts. Per la maggior parte delle organizzazioni che operano su AWS, Google Cloud o Azure su larga scala, la spesa on-demand non coperta su workloads stabili è una delle più grandi lacune di efficienza dei costi da colmare. Un team con il 40% di copertura commitments su workloads che girano 24/7 lascia sul tavolo risparmi consistenti.
Il potenziale di right-sizing è la stima aggregata dei risparmi ottenibili ridimensionando o modificando le risorse sovradimensionate nel suo ambiente. È più azionabile della semplice percentuale di utilizzo perché esprime l'opportunità in valuta, l'unità di misura a cui rispondono sia i responsabili engineering sia quelli finance.
Metriche di spreco: risorse inattive, storage orfano e spesa non allocata
Le metriche di spreco identificano la spesa cloud che non produce alcun valore di business. Sono gli obiettivi di ottimizzazione a più alta priorità, perché i risparmi sono di fatto privi di rischio. Non c'è alcun trade-off sulle performance da analizzare, nessuno stakeholder da convincere, nessuna modifica architetturale richiesta.
Tra le risorse inattive rientrano le istanze fermate ma ancora fatturate, i load balancer collegati a servizi dismessi e gli ambienti di sviluppo lasciati attivi nei fine settimana e nei giorni festivi. Il costo unitario della singola risorsa inattiva è raramente elevato. Il totale aggregato, in un'organizzazione di engineering di medie dimensioni, di solito lo è.
Lo storage orfano si accumula quando le risorse di compute vengono terminate, ma i volumi, gli snapshot e i backup associati no. Bucket di object storage di progetti deprecati, snapshot di database di ambienti che non esistono più e archivi di log che hanno superato la finestra di retention rientrano tutti in questa categoria. Lo storage orfano è particolarmente comune nelle organizzazioni che si muovono in fretta sul provisioning dell'infrastruttura senza una pari disciplina di decommissioning.
La spesa non allocata si riferisce agli addebiti cloud che non si possono attribuire a un team, a un prodotto o a un centro di costo a causa di tag mancanti o incoerenti. È una metrica di spreco di altro tipo: non rappresenta risorse che non generano valore, ma risorse che generano un valore sconosciuto. Non si può ottimizzare ciò che non si può attribuire, e la spesa non allocata è l'indicatore anticipatore di una lacuna di governance dei costi che sarà sempre più difficile colmare man mano che l'ambiente cresce.
Metriche di business: unit economics e costo in percentuale sui ricavi
Le metriche di business sono il punto in cui il FinOps passa da funzione di riduzione dei costi a funzione strategica. Le unit economics, espresse come costo per cliente, costo per transazione, costo per chiamata API o costo per utente attivo, rispondono alla domanda a cui le metriche finanziarie non arrivano: questa spesa cloud è efficiente rispetto al valore di business che genera?
Un'azienda che spende 2 milioni di dollari al mese in infrastruttura cloud e cresce nei ricavi del 40% anno su anno si trova in una posizione molto diversa da un'altra con la stessa bolletta e crescita piatta. La spesa totale come metrica tratta le due situazioni allo stesso modo. Il costo in percentuale sui ricavi, o il costo per unità di output di business, le distingue.
Le unit economics cambiano anche il tenore della conversazione con i team di engineering. Dire a un team che il suo servizio costa 180.000 dollari al mese raramente produce azione. Dirgli che il suo servizio costa 0,23 dollari per utente attivo, e che il leader di mercato è a 0,11 dollari, apre invece un confronto sul design. La metrica collega il costo cloud alle performance di prodotto in un linguaggio che gli engineer trovano azionabile.
Costruire le unit economics richiede di collegare i dati di fatturazione cloud ai dati di business, in particolare il livello applicativo che mappa i costi infrastrutturali sui prodotti e sull'attività dei clienti che essi supportano. È tecnicamente più difficile che monitorare l'utilizzo o lo scostamento dal budget, ed è per questo che è una metrica da stadio maturo. Ma è anche il punto in cui vivono le decisioni di ottimizzazione con la leva più alta.
Come scegliere le metriche giuste per il proprio stadio di maturità FinOps?
Il framework crawl/walk/run della FinOps Foundation offre una mappa utile per stabilire le priorità delle metriche. Le metriche giuste non sono le più sofisticate a disposizione. Sono quelle che rispondono alle domande a cui il suo business può effettivamente rispondere ora, con la qualità dei dati e gli strumenti di cui dispone.
Stadio iniziale: metriche di visibilità
Allo stadio crawl, il problema principale è che i costi non sono visibili né attribuibili. Si vede una bolletta totale. Non si vede quali team, servizi o prodotti la stiano generando. Le metriche che contano qui sono quelle fondamentali: tasso di copertura del tagging, costo per account e servizio, scostamento dal budget per business unit.
La copertura del tagging è una metrica di input, non di output: misura quanta parte della sua spesa cloud porta con sé i metadati di attribuzione che rendono possibile tutto il resto. I team che saltano questo passaggio e vanno dritti alle metriche di ottimizzazione finiscono per ottimizzare le parti di infrastruttura che vedono, ignorando quelle che non vedono.
L'obiettivo dello stadio crawl non è l'ottimizzazione perfetta. È costruire la baseline che rende possibile l'ottimizzazione.
Stadio intermedio: metriche di ottimizzazione
Allo stadio walk la visibilità è consolidata e il team è pronto ad agire. Le metriche che contano ora sono quelle che identificano opportunità di ottimizzazione e verificano che gli interventi producano risparmi reali: copertura dei commitments, potenziale di right-sizing, spreco in percentuale sulla spesa totale e accuratezza del forecast.
La copertura dei commitments merita un'attenzione particolare in questo stadio. È una delle leve di ottimizzazione a più alto ritorno disponibili e richiede un overhead operativo relativamente basso una volta che è stata stabilita una disciplina di acquisto. I team che fissano target di copertura commitments e costruiscono un processo per rivederli e adeguarli trimestralmente ottengono in genere risparmi stabili che si sommano nel tempo.
Anche l'accuratezza del forecast diventa importante in questo stadio, perché il team ha ormai un dialogo regolare con finance e leadership sulla spesa cloud. Forecast che sbagliano sistematicamente del 20% o più minano la credibilità del team FinOps come funzione di pianificazione, a prescindere dallo spreco che è riuscito a eliminare.
Stadio maturo: metriche di efficienza e valore di business
Allo stadio run il team dispone di visibilità stabile, programmi di ottimizzazione attivi e forecasting affidabile. Le metriche che contano ora sono quelle che collegano le performance del cloud a quelle del business: unit economics, costo in percentuale sui ricavi e rapporti di efficienza per workload o prodotto.
È anche lo stadio in cui il rilevamento delle anomalie diventa uno strumento strategico anziché reattivo. I team maturi usano gli alert di anomalia sui costi non solo per intercettare la spesa fuori controllo, ma per cogliere il segnale anticipatore di inefficienze architetturali: un nuovo servizio che consuma il triplo di compute rispetto al suo predecessore, un batch job che scansiona più dati del previsto o una feature che genera una quota sproporzionata di spese di egress.
La capability DataHub di DoiT collega direttamente i dati di fatturazione cloud alle metriche di business, rendendo trattabili le unit economics senza richiedere lavoro custom sulle pipeline di dati. Per i team che hanno consolidato le discipline di visibilità e ottimizzazione ma non hanno ancora costruito il livello dati che rende misurabili le unit economics, è il ponte tra il reporting da stadio walk e quello da stadio run.
Quali sono le trappole più comuni nel monitoraggio delle metriche di cloud cost optimization?
Diverse metriche molto diffuse sembrano utili, ma disorientano sistematicamente i team FinOps. Sapere dove sono le trappole permette di risparmiare tempo e credibilità che altrimenti si perderebbero cadendovi dentro.
Ragionare solo sull'utilizzo è l'errore più frequente. Un utilizzo elevato assomiglia all'efficienza. In molti casi lo è davvero. Ma un cluster Kubernetes al 90% di utilizzo CPU potrebbe scontrarsi con vincoli di performance che rallentano i tempi di risposta dell'applicazione. Un database all'85% di utilizzo memoria potrebbe rallentare le query. L'utilizzo senza il contesto delle performance confonde la pressione sulle risorse con l'efficienza delle risorse. Monitori l'utilizzo insieme alle metriche di performance, non al loro posto.
Monitorare la spesa totale in modo da penalizzare la crescita crea gli incentivi sbagliati. Se il KPI principale del team FinOps è la riduzione della spesa cloud totale, il team ottimizzerà per la riduzione della spesa, a volte a scapito della velocity di engineering o delle capacità di prodotto che hanno spinto all'adozione del cloud in prima battuta. La spesa totale è un input utile alla conversazione, non una metrica di successo. Il costo in percentuale sui ricavi, o il costo per unità di output di business, è un proxy migliore per capire se la spesa cloud è sana.
L'analisi cieca all'intento applica benchmark generici a workloads con finalità specifiche. Un job di training di machine learning che gira al 40% di utilizzo GPU durante il preprocessing dei dati non è sovradimensionato. Sta eseguendo la fase di preprocessing di una pipeline che salirà al 95% durante il training. Un ambiente di disaster recovery che resta inattivo per la maggior parte del tempo non è spesa sprecata: è un'assicurazione. Le raccomandazioni di right-sizing che ignorano l'intento del workload producono modifiche che tagliano i costi e, allo stesso tempo, ne compromettono l'affidabilità.
L'accumulo di vanity metric, cioè monitorare più metriche perché di più sembra sinonimo di rigore, produce overhead di reporting senza profondità analitica. Se una metrica non è collegata a una decisione o a un'azione, sta consumando attenzione che potrebbe andare alle metriche che invece lo sono.
Come si costruisce una pratica di metriche che riduca davvero i costi cloud?
Le metriche senza un livello di azione sottostante restano dashboard. Un numero che viene esaminato, discusso e archiviato non ottimizza nulla. Un numero che innesca una risposta definita - una raccomandazione di right-sizing inviata a uno specifico team di engineering, una lacuna di copertura commitments che apre una revisione degli acquisti o uno scostamento di forecast che attiva un'indagine sulle anomalie - produce risultati.
La differenza tra i team che usano le metriche in modo efficace e quelli che non lo fanno di solito si riduce a tre pratiche. Definiscono le soglie di risposta prima di averne bisogno: se la copertura commitments scende sotto l'X%, si attiva la revisione degli acquisti. Assegnano l'ownership delle metriche: qualcuno è responsabile dell'accuratezza del forecast così come qualcun altro lo è dell'uptime. E chiudono il cerchio tra metrica e risultato: quando una raccomandazione di right-sizing viene implementata, i risparmi vengono misurati e comunicati al team che l'ha messa in atto.
L'automazione amplifica tutte e tre le pratiche. Le revisioni manuali delle metriche non scalano con la crescita dell'infrastruttura. I team che automatizzano il rilevamento delle anomalie, il presidio della compliance sui tag e l'identificazione routinaria degli sprechi liberano l'attenzione degli engineer per il lavoro di ottimizzazione che richiede giudizio: decisioni architetturali, strategia di commitment e design dei workloads.
Il report 2025 State of FinOps della FinOps Foundation ha rilevato che l'ottimizzazione dei workloads e la riduzione degli sprechi restano la priorità principale per oltre il 50% dei professionisti FinOps, e i team che avanzano più rapidamente su entrambi i fronti non monitorano più metriche. Agiscono su un numero minore di metriche, migliori, più velocemente.
La piattaforma FinOps di DoiT mette a disposizione dei team analytics, rilevamento delle anomalie e mappatura delle metriche di business tramite DataHub per passare dal monitoraggio all'azione. Se la sua pratica di metriche ha superato le capacità dei suoi strumenti, parli con il nostro team per scoprire come DoiT trasforma i dati sui costi cloud in azione automatizzata.
Domande frequenti
Quali sono le metriche di cloud cost optimization più importanti per un team FinOps di nuova costituzione?
Un team FinOps appena costituito dovrebbe partire da tre metriche: tasso di copertura del tagging, costo per account e servizio, scostamento dal budget per business unit. Queste metriche di livello visibilità stabiliscono la base di attribuzione che rende possibile tutto il resto. Le metriche di utilizzo e di spreco sono più difficili da azionare quando i costi non sono ancora attribuibili a team o workloads specifici. Costruisca prima la baseline, poi aggiunga le metriche di ottimizzazione una volta che la spesa è visibile e assegnata. Cercare di ottimizzare prima di riuscire a vedere con chiarezza produce interventi puntuali che non si sommano nel tempo.
In cosa differiscono le unit economics dalle metriche di utilizzo?
Le metriche di utilizzo misurano quanta parte di una risorsa provisionata un workload consuma. Le unit economics misurano quanto costa erogare un'unità di valore di business: un cliente servito, una transazione elaborata, una chiamata API completata. L'utilizzo dice se una risorsa viene usata. Le unit economics dicono se usarla è efficiente rispetto a ciò che il business ottiene in cambio. Un cluster molto utilizzato che esegue un workload a basso valore appare sano su una dashboard di utilizzo e scadente su un report di unit economics. Le due metriche rispondono a domande diverse e le pratiche FinOps mature hanno bisogno di entrambe.
Qual è un buon target di accuratezza per il forecast dei costi cloud?
La maggior parte delle organizzazioni considera accettabile uno scostamento del 10-15% tra forecast e valori effettivi. I team con strategie di commitment mature, workloads stabili e allocazione dei costi pulita spesso arrivano al 5% o meglio. Un'inquadratura più utile è quella dell'accuratezza direzionale: un forecast costantemente basso del 12% è un problema di calibrazione risolvibile. Un forecast a volte alto del 5% e a volte basso del 25% segnala un problema di qualità del dato o di attribuzione che nessun modello di forecasting riuscirà a risolvere. Migliori prima la copertura del tagging e la visibilità a livello di account, poi si concentri sul restringere l'intervallo di scostamento.