Cloud Intelligence™
Report di cui il finance si fida davvero
Questa pagina è disponibile anche in English, Deutsch, Español, Français, 日本語 e Português.
About Devorah Klartag
Marketing director. 15+ years turning marketing vision into infrastructure that actually scales - GTM, demand gen, ops, and the AI-powered systems that keep the whole thing moving. At Attribute, I built the marketing function from the ground up and hit top-3 AI search rankings on competitive FinOps queries in ChatGPT, Perplexity, and Claude.
Previously: senior growth and marketing ops at D-ID (led the self-service studio launch that hit #1 Product of the Day on Product Hunt and landed coverage in TechCrunch, Fast Company, and Forbes), digital marketing at CyberProof, and $7M campaigns at McCann Tech for NICE and Amdocs. Earlier, hospitality marketing across NYC restaurants and cruise lines.
Ex-New Yorker in Tel Aviv. Still misses the bagels most.
My personal pageHa passato mesi a costruire report e dashboard. Costi per team, costi per workload, chargeback per business unit. Agli engineer tutto sembra corretto. Poi il finance partecipa alla review e chiede: "Può dimostrare questi numeri?"
È complicato. I Suoi strumenti lavorano su export di fatturazione, motori di regole e una copertura dei tag ferma al 70%. Non è abbastanza solido per decisioni di business, previsioni e proiezioni.
PerfectScale™ for Kubernetes
Ready to optimize?
Get your free Kubernetes savings analysis
Perché i numeri non reggono
Gli strumenti FinOps sono nati per leggere il file di fatturazione generato dal cloud provider, segmentarlo con regole e tag e mostrare il risultato in una dashboard.
Il finance e il management pongono domande da un'altra prospettiva. Quanto costa servire il cliente X? Quale dei nostri prodotti ha margini positivi? La maggior parte degli strumenti FinOps fornisce una risposta. Pochissimi ne forniscono una verificabile.
Cosa significa davvero "spazzatura"
Quando uno stakeholder definisce un report dei costi "spazzatura", o sta reagendo a numeri che non corrispondono a ciò che sa essere vero, oppure non riesce a capire come quei numeri siano stati calcolati.
Nella pratica, di solito si riduce a tre cose:
Regole che un tempo avevano senso, ma sono invecchiate.
Le regole di allocazione sono state configurate 18 mesi fa. Tre migrazioni e due rebrand di prodotto dopo, le regole puntano ancora a servizi ed etichette che non significano più quello che significavano allora. Nella dashboard i numeri sembrano coerenti perché le regole vengono eseguite in modo coerente. Nessuno ha verificato se le regole fossero ancora corrette. Tutti davano per scontato che la pulizia fosse compito di qualcun altro.
Tag che non hanno mai raggiunto la copertura completa.
L'attribuzione basata sui tag copre solo le risorse taggate. Il 30% che l'engineering non ha mai taggato viene scartato o distribuito tramite una ripartizione sintetica. Quando il finance chiede "cosa c'è nel bucket non allocato", la risposta onesta è: una parte significativa della spesa effettiva. L'inferenza AI peggiora la situazione: la maggior parte dei team non ha ancora capito come taggare le chiamate ai modelli, figuriamoci per feature o per cliente.
Dati obsoleti nel modello. Vecchi account, servizi dismessi, contratti terminati, ma i dati storici sono ancora nel modello.
Il problema del P&L di prodotto
Il problema di fiducia si aggrava quando i team FinOps provano a rispondere alla vera domanda del finance: non "quanto costa questo workload", ma "quanto costa questo prodotto, per regione, per tier di clienti?"
Rispondere a quella domanda richiede più dei soli dati di costo. A un cliente che utilizza tre prodotti in cinque regioni non interessa a quale namespace Kubernetes faccia capo la spesa. Gli interessa sapere se il cliente è redditizio. Occorre sapere quale workload serve quale prodotto, quali clienti consumano quali workloads e come l'infrastruttura condivisa si ripartisce tra tutti questi elementi. Gli strumenti FinOps standard possono approssimarlo con abbastanza tagging e regole. Ma le approssimazioni non sopravvivono a un VP che chiede la metodologia sottostante.
Ciò che il finance vuole davvero è il cost-to-serve a livello di cliente e di prodotto, incluse le componenti fisse e variabili e la spesa SaaS di terze parti come Snowflake o Twilio, in un formato difendibile davanti al board. Ai team pricing serve per definire i margini. Al finance serve per rendicontare il COGS. Ai product leader serve per capire quali feature stanno erodendo il margine.
La maggior parte degli strumenti di gestione dei costi cloud è molto efficace nel rispondere a "perché la nostra fattura AWS è aumentata?". Ma non è mai stata progettata per rispondere a "questo prodotto sta generando profitto?"
Lo stesso problema sta ora arrivando più velocemente dalla spesa AI. I costi di inferenza LLM non si comportano come EC2. Sono legati alle richieste, variano per singolo cliente e crescono rapidamente. Un export di fatturazione dice quanto Bedrock o OpenAI hanno addebitato il mese scorso. Non dice quale feature di prodotto lo ha generato, quale tier di clienti lo ha consumato o se le unit economics reggono su larga scala. Volume di token, scelta del modello, lunghezza dei prompt: niente di tutto questo corrisponde a una riga di fatturazione. Il finance sta iniziando a fare domande sul COGS dell'AI come le fa sul COGS del cloud. Il gap nei dati è identico. La posta in gioco è più alta perché i costi si muovono più velocemente.
Your cloud bill shouldn't be a mystery
Optimization, automation, expertise. In one platform.
Il problema di ricostruire la realtà
Ogni strumento basato su export di fatturazione ha lo stesso limite strutturale. Il file di fatturazione dice cosa è stato addebitato. Non dice perché, quali clienti lo hanno generato o come le risorse condivise si ripartiscono realmente tra i consumatori.
Attribute legge il sistema live invece del file di fatturazione. Un sensore eBPF ultraleggero installato sull'infrastruttura di compute osserva quali workloads comunicano con quali database e servizi utilizzando dati a runtime, a livello di rete. L'attribuzione dei costi segue il comportamento effettivo, non regole sul comportamento atteso.
La differenza conta soprattutto quando uno stakeholder chiede come è stato ottenuto un numero. Con l'attribuzione basata sulla fatturazione, si risale attraverso una catena di regole e ipotesi. Con l'attribuzione a runtime, si risale all'attività di rete osservata.
Come si traduce tutto questo nella pratica
Prendiamo la visibilità dei costi per team, una delle richieste FinOps più comuni. Con uno strumento basato sul tagging, la visibilità sui costi per team è buona solo quanto lo sono la copertura dei tag e la pulizia delle label. I namespace condivisi sono un problema. I servizi che l'engineering ha rilasciato la settimana scorsa e non ha ancora taggato sono invisibili.
Il sensore di Attribute rileva automaticamente i nuovi workloads, perché li osserva comunicare nell'infrastruttura invece di aspettare che qualcuno li etichetti. Quando il Suo team deve mostrare i " costi addebitabili per team", l'approccio a runtime produce un numero difendibile perché riflette ciò che è effettivamente in esecuzione.
Lo stesso principio vale a livello di cliente. Se deve sapere quanto costa davvero servire un cliente specifico, tra infrastruttura fissa, compute variabile e strumenti SaaS, non può ottenerlo da un export di fatturazione senza un notevole lavoro di mappatura manuale. Attribute costruisce quella mappatura a partire da ciò che osserva: quali workloads dei clienti toccano quali servizi, in che volume, a quale costo. Quando i clienti chiedono il costo di prodotto per regione o la redditività di prodotto nei diversi tipi di servizio, quella domanda ha una risposta reale, non una stima.
Lo stesso vale per i costi AI. Il sensore di Attribute legge le chiamate a livello di rete: quale servizio ha effettuato la chiamata, quale workload cliente l'ha attivata e quanto è costata. È il numero che un team pricing può usare per decidere se assorbire il costo di inferenza o ribaltarlo sul cliente.
Attribute aiuta i team FinOps e finance a capire che cosa la spesa cloud e SaaS sta effettivamente finanziando, grazie all'attribuzione a runtime al posto di tag manuali ed export di fatturazione.
Perché i report dei costi cloud non superano le review del finance?
La maggior parte degli strumenti FinOps costruisce i report a partire da export di fatturazione, regole di allocazione e tag. Le regole invecchiano. La copertura dei tag è raramente completa. Quando il finance chiede come è stato calcolato un numero, la risposta onesta risale a una catena di ipotesi, non a dati osservati. È questo il gap.
Che cos'è l'attribuzione dei costi a runtime?
Attribuzione a runtime significa che i costi seguono il comportamento effettivo del sistema, non regole sul comportamento atteso. Attribute installa un sensore eBPF che osserva quali workloads comunicano con quali servizi a livello di runtime. Ogni costo risale ad attività di rete osservata, non a una decisione di tagging presa 18 mesi fa.
Come viene gestita la spesa senza tag?
Con gli strumenti basati sul tagging, le risorse non taggate vengono scartate o distribuite tramite una ripartizione sintetica. Il sensore di Attribute rileva i workloads indipendentemente dal fatto che siano stati etichettati, perché li osserva comunicare nell'infrastruttura. I nuovi servizi rilasciati la settimana scorsa sono visibili immediatamente.
Attribute può mostrare il cost-to-serve per cliente?
Sì. Attribute mappa la spesa cloud e SaaS sui singoli clienti finali osservando quali workloads dei clienti toccano quali servizi, in che volume, a quale costo. Il risultato è un vero cost-to-serve, che include infrastruttura fissa, compute variabile e strumenti di terze parti come Snowflake o Twilio.
E i costi di inferenza AI e LLM?
I costi di inferenza non compaiono negli export di fatturazione con un livello di dettaglio utile. Il sensore di Attribute legge le chiamate ai modelli a livello di rete, attribuendo ogni richiesta al servizio, al cliente e alla feature che l'hanno attivata. È il numero di cui i team pricing hanno bisogno per definire i margini sulle feature AI.
In cosa è diverso da CloudZero o Apptio?
Quegli strumenti lavorano su export di fatturazione e richiedono il tagging prima di mostrare dati significativi. Attribute legge invece il sistema live. Nessun tagging richiesto, nessuna manutenzione delle regole, e la metodologia regge quando uno stakeholder chiede come è stato ottenuto un numero.
