Attribuzione dei costi cloud e AI: la guida completa

Situazione	Basta l'export di fatturazione?
Infrastruttura single-tenant semplice	Sì
Team ridotto, un solo account cloud	Sì
Microservizi Kubernetes	Di norma no
Prodotto SaaS multi-tenant	No
RDS, Kafka o Elasticsearch condivisi	No
Allocazione dell'inferenza AI per cliente o feature	No
Analisi del margine per cliente	No
Infrastruttura self-managed (sistemi dati su EC2)	No
Attribuzione di NAT gateway e data transfer	No

Se il Suo ambiente ricade nella parte bassa di questa tabella, gli export di fatturazione sono solo un punto di partenza: non sono uno strumento di ottimizzazione dei costi. Per i team che portano in produzione feature AI, il divario è ancora più marcato: la spesa in token è solo una porzione della superficie di costo dell'AI. Vector database, livelli di orchestrazione, egress e infrastruttura self-managed attorno alla chiamata al modello rappresentano abitualmente dal 40 al 60% della spesa totale di una feature. Gli strumenti che leggono solo la fattura dei token ne ignorano la parte più consistente.

La fatturazione cloud è stata pensata per un modello statico: si esegue il provisioning di una risorsa, le si applica un tag, si legge il tag a fine mese.

Kubernetes ha fatto saltare ogni presupposto su cui quel modello si regge. I pod sono effimeri. I servizi condividono l'infrastruttura oltrepassando i confini di team e tenant. Una singola richiesta cliente attraversa più servizi prima che venga restituita una risposta. Il risultato: nessun tag registra chi ha consumato cosa, ma solo chi possiede la risorsa. E la ownership non coincide con il consumo.

Gran parte degli strumenti di monitoraggio dei costi Kubernetes reagisce misurando a livello di cluster: allocazione CPU, memory request, pod-hour. È un contesto utile, ma non è attribuzione dei costi. RDS, Kafka, Snowflake e il data transfer sono spesso voci di spesa rilevanti e sistematicamente sotto-attribuite accanto al cluster. Gli strumenti che si fermano al livello di nodo e pod lasciano la maggior parte della fattura senza destinatario.

Ne derivano quattro fallimenti prevedibili:

• Il tagging diventa il progetto. I tag registrano la ownership, ma non riescono ad attribuire il consumo delle risorse condivise. Il progetto va avanti per mesi e non arriva mai davvero a conclusione.
• I costi condivisi si allocano a occhio. Percentuali statiche e ripartizioni in parti uguali. Difendibili in un foglio di calcolo, ma non accurate.
• Manca l'attribuzione a livello di cliente. La spesa totale è visibile, il costo per tenant no. Account redditizi e in perdita appaiono identici.
• I dati arrivano troppo tardi. L'export di fatturazione si chiude a fine mese. Lo spreco è già avvenuto.

L'attribuzione a runtime parte da una fonte dati completamente diversa: ciò che sta effettivamente accadendo nel sistema in questo momento.

Attribute™ installa un sensore eBPF sull'infrastruttura di calcolo: nodi EKS, task ECS, istanze EC2, auto scaling group. eBPF (extended Berkeley Packet Filter) è una tecnologia del kernel Linux che consente un'osservazione sicura e sandboxed dell'attività di sistema a livello kernel. Il sensore ispeziona i pacchetti di rete in sola lettura, senza overhead prestazionale e senza modifiche al codice applicativo.

Cosa osserva il sensore:

• Ogni chiamata di rete tra i servizi
• Quale microservizio interroga quale database e con quale frequenza
• Come viene realmente consumata l'infrastruttura condivisa
• Quali endpoint delle API AI sono chiamati da quali workloads, con quale volume di token, e a quale cliente, feature o agente vanno attribuiti
• Gli header HTTP che veicolano gli identificativi cliente
• Destinazioni e volumi del data transfer

Da queste osservazioni, Attribute™ costruisce un grafo di dipendenze dei servizi in tempo reale. Sa quali servizi dipendono da quali risorse, con quale intensità e in quali proporzioni. Quel grafo è il modello di attribuzione.

Quando un'istanza RDS condivisa genera costi, il modello non applica una regola statica: analizza la distribuzione effettiva delle query al database tra i servizi in quel periodo e alloca il costo in proporzione al consumo reale.

I nuovi servizi vengono rilevati automaticamente non appena compaiono. Le relazioni si aggiornano al variare dei deployment. Nessun catalogo servizi statico. Nessuna riconfigurazione manuale.

Case study cliente: Island

Il contesto: Island sta costruendo la categoria dell'enterprise browser con una valutazione da 5 miliardi di dollari e scala verso centinaia di clienti enterprise. Il loro ambiente AWS si basa su EKS, RDS e DynamoDB condivisi, con un data transfer AZ-to-AZ significativo. Il tagging non era percorribile: in un'architettura multi-tenant non si può applicare un tag a un cliente.

Prima: nessuna visibilità sul reale costo per cliente o per feature. Nessun modo di supportare pricing, modelli di crescita o decisioni GTM con dati di costo reali. Gli strumenti nativi del cloud e le piattaforme di terze parti mostravano fatture e grafici, ma non erano in grado di dire quanto costasse davvero ogni cliente.

Dopo: Attribute™ ha fornito costi accurati per cliente e per feature nel giro di pochi giorni. Senza tagging, senza strumentazione, senza richieste all'engineering.

Il cambiamento operativo: engineering, product e GTM lavorano oggi su un'unica fonte di costo condivisa. Le decisioni su pricing e modelli di crescita si basano su dati di consumo reali, non su stime.

"In un ambiente multi-tenant non si può applicare un tag a un cliente. Attribute™ ci mostra finalmente quanto costa ogni cliente e cosa determina quei costi.",

– Omri Cohen, Director of Engineering Platform, Island

Vuole approfondire? Qui può leggere come una piattaforma leader di Work Management ha individuato 360 account in perdita, oppure qui come un'azienda di sicurezza ha unificato il reporting tra Finance ed Engineering.

L'unit economics richiede un modello di costo che si mappi sull'unità reale. Per un'azienda SaaS, quell'unità è di norma il cliente.

A questa domanda gli export di fatturazione non sanno rispondere. La fatturazione mostra i costi delle risorse, ma non quali clienti le hanno consumate né in quali proporzioni.

Il livello di attribuzione al cliente di Attribute™ mappa l'attività a runtime osservata su identificativi cliente ricavati da header HTTP, label dei workloads o convenzioni di naming di database e code. Una volta impostato, ogni evento di costo del modello viene attribuito al cliente che lo ha generato.

Collegando i dati di revenue, l'output è un P&L a livello di cliente: quali account sono redditizi, quali no e di quanto.

Cosa abilita questa visibilità:

• Individuare gli account a margine negativo prima che le perdite si accumulino
• Intercettare le feature AI con costi fuori controllo prima che si chiuda il ciclo di fatturazione
• Fornire ai team di piattaforma numeri difendibili per il chargeback dell'infrastruttura condivisa
• Definire il prezzo dei contratti enterprise a partire dal consumo reale, non da ipotesi
• Giustificare gli investimenti architetturali con dati di costo reali prima/dopo
• Chiudere la disputa mensile tra finance ed engineering sulla metodologia di allocazione

Time to value: il sensore viene installato su Kubernetes tramite un DaemonSet. La discovery iniziale dei workloads si completa in poche ore. L'attribuzione dei costi diventa significativa nel giro di pochi giorni. Nessun progetto di tagging richiesto.

Overhead prestazionale: il sensore eBPF è in sola lettura e sandboxed a livello kernel. Non intercetta né modifica il traffico. L'overhead di calcolo è trascurabile.

Integrazioni: Attribute™ viene installato sull'infrastruttura di calcolo (EKS, ECS, EC2) e monitora il traffico dal livello applicativo verso le altre risorse cloud, inclusi provider SaaS di terze parti come MongoDB Atlas, Snowflake, OpenAI e altri. Nessuna strumentazione a livello applicativo.

Sostituisce Kubecost o CloudHealth? Per le aziende SaaS le cui domande sui costi vanno oltre il reporting a livello di cluster, sì. Attribute™ va oltre sull'attribuzione delle risorse condivise, sul cost-to-serve a livello di cliente, sulla copertura dell'infrastruttura self-managed e sulla piena visibilità della superficie di costo AI, inclusa l'attribuzione dei token per cliente, feature o agente, insieme alla spesa infrastrutturale circostante che quegli strumenti non vedono.

Dati storici: lo storico di fatturazione cloud viene importato in fase di setup. Per i team che hanno bisogno di deliverable di chargeback prima ancora di installare il sensore, Attribute™ può generare report a partire dagli export di fatturazione forniti dal cliente, senza sensore.

Ambienti supportati: AWS, GCP, Azure. Kubernetes (EKS, GKE, AKS), ECS, EC2. Snowflake, MongoDB Atlas, OpenAI, Anthropic, Amazon Bedrock, Azure OpenAI, Vertex AI. Kafka self-managed (con granularità a livello di topic), Elasticsearch, RabbitMQ.

Sicurezza: PII, credenziali, secret, API key e cookie vengono rimossi prima che qualsiasi dato lasci l'ambiente del cliente. Vengono trasmessi eventi minimi tramite OpenTelemetry cifrato, autenticato via JWT e protetto da TLS. I pacchetti grezzi non vengono mai trasmessi. Il cliente può facoltativamente instradare la telemetria attraverso un proprio endpoint OpenTelemetry, mantenendo piena capacità di audit.

Gli strumenti basati sulla fatturazione si chiedono cosa è stato addebitato. L'attribuzione a runtime si chiede cosa è realmente accaduto nel sistema e chi lo ha causato.

Per i team che valutano l'acquisto di una piattaforma, cinque domande separano gli strumenti in grado di rispondere alle domande che contano da quelli che non ci riescono:

1. Funziona senza tag fin dal primo giorno?
2. Sa allocare i costi delle risorse condivise sulla base del consumo osservato anziché di regole statiche?
3. Sa attribuire i costi per cliente in un sistema multi-tenant?
4. Riesce a vedere l'infrastruttura self-managed e la spesa AI esterna?
5. Sa far emergere i segnali di costo durante il ciclo di fatturazione, e non a chiusura avvenuta?

Per i team con una spesa AI rilevante, ne aggiunga una sesta: sa attribuire i costi dei token a uno specifico cliente, feature o agente, e non solo a una chiave API? Gli strumenti basati sulla fatturazione rispondono parzialmente ad alcune di queste domande, per alcuni ambienti e con un investimento di setup significativo. L'attribuzione a runtime risponde a tutte fin dal deployment.