Come monitorare i costi per cliente in un'architettura multi-tenant su AWS

AWS Cost Explorer e ogni strumento basato sulla fatturazione restituiscono il costo per account, regione, servizio e tag. Va benissimo per i modelli dedicated-tenant, in cui ogni cliente dispone del proprio account o namespace. Non funziona con l'infrastruttura condivisa.

Un singolo cluster RDS che serve 400 clienti non genera 400 voci di costo: ne genera una sola. Un cluster Kafka usato da una dozzina di team di prodotto compare comunque come un unico centro di costo condiviso. Un node pool EKS che esegue workloads misti viene fatturato come compute, non come "cliente A: 142.000 $, cliente B: 89.000 $".

L'approccio basato sui tag si scontra qui con tre limiti:

1. I tag non si propagano attraverso le risorse condivise. Si può taggare un'istanza EC2 con un team o un servizio, ma non si può taggare una query eseguita su un database condiviso.
2. I tag richiedono uno sforzo di engineering costante. Ogni nuova risorsa, ogni nuovo servizio, ogni nuovo deployment ha bisogno di un tag. Nelle organizzazioni che corrono, la copertura si degrada in fretta.
3. I tag dicono cos'è la risorsa, non come è stata usata. Un'istanza RDS taggata indica che appartiene al servizio "payments", ma non rivela che il 60% del carico del mese è arrivato da un solo cliente.

Come funziona: anziché leggere gli export di fatturazione o aggiungere strumentazione applicativa, si osserva ciò che avviene realmente a livello di rete e di sistema: quali servizi interrogano quali database, quali customer ID compaiono in quali query, quanto carico ciascun cliente genera sulle singole risorse condivise.

La differenza cruciale è questa: i sistemi di fatturazione vedono solo gli addebiti, i sistemi a runtime vedono il consumo effettivo.

In pratica, è uno dei pochi approcci capaci di attribuire sistemi condivisi come RDS, Kafka o Elasticsearch ai singoli clienti senza richiedere modifiche applicative né una disciplina di tagging impeccabile.

Offre inoltre un'attribuzione in tempo reale invece di export CUR con ritardo e riesce a coprire anche infrastrutture self-managed che nei dati di fatturazione AWS non compaiono mai in modo pulito.

Il compromesso: serve un componente in grado di osservare il traffico di rete e le chiamate di sistema. In passato, raccogliere dati a runtime di questo livello in produzione era operativamente oneroso. eBPF ha cambiato le regole del gioco. Le stesse primitive che stanno alla base di strumenti come Cilium, Falco e Pixie possono essere sfruttate anche per l'attribuzione dei costi a runtime. La differenza è che si estraggono segnali di consumo delle risorse invece di eventi di sicurezza o di observability.

Come funziona: a ogni cliente viene assegnato un account AWS o un namespace Kubernetes dedicato, con la fatturazione isolata di conseguenza.

Dove funziona: settori ad alta compliance (sanità, finanza), contratti enterprise con requisiti contrattuali di isolamento, clienti abbastanza grandi da giustificare economicamente un'infrastruttura dedicata.

Dove si inceppa: non regge su centinaia di clienti SMB. L'overhead operativo di gestire centinaia di account AWS è notevole. La copertura delle Reserved Instance si frammenta. E restano comunque i servizi condivisi (pipeline di logging, infrastruttura di observability, data plane) che vivono al di fuori degli account per-tenant.

Come funziona: si applicano standard di tagging a tutte le risorse, usando tag come customer-id, team, service ed environment. I dati di costo taggati si estraggono tramite l'API di Cost Explorer o gli AWS Cost and Usage Reports (CUR). Sopra si costruisce la logica di aggregazione.

Dove funziona: architetture greenfield in cui gli standard di tagging vengono imposti fin dal primo giorno. Regge abbastanza bene per il compute dedicato (EC2, node group EKS, Lambda), dove il mapping tra risorsa e cliente è netto.

Dove si inceppa:

• Crolla non appena più clienti condividono gli stessi sistemi stateful. Un cluster RDS condiviso o un deployment Kafka hanno per definizione una sola fattura e molti consumatori.
• Nella pratica, poche organizzazioni mature riescono a mantenere a lungo una copertura di tagging pulita. Le ownership cambiano, i servizi proliferano e i tag decadono.
• I dati CUR arrivano con 24-48 ore di ritardo: si guarda sempre al passato.
• Le risorse condivise (Kafka self-managed, Elasticsearch su EC2) sono del tutto invisibili agli export di fatturazione.

La maggior parte dei team che lo adotta convive con punti ciechi importanti, di cui è consapevole e che sceglie di accettare.

Come funziona: si strumenta il codice applicativo perché emetta metriche per cliente: query eseguite, byte letti/scritti, tempo di compute consumato. Si costruisce poi un modello di costo che associa quelle metriche alla spesa AWS. Moltiplicando il consumo delle metriche per il costo unitario si ottiene una stima del costo per singolo cliente.

Dove funziona: team con una solida cultura dell'observability, applicazioni in cui il consumo di risorse è dominato da un numero ridotto di operazioni misurabili, team di pricing di prodotto che si accontentano di un'approssimazione.

Dove si inceppa:

• La copertura della strumentazione è incompleta per definizione: si misura solo ciò che si è scelto di misurare.
• L'infrastruttura condivisa (connection pooling, overhead del cluster, capacità inattiva) non è attribuibile ad alcuna operazione specifica.
• I modelli di costo richiedono una calibrazione continua ogni volta che i prezzi cambiano.
• L'infrastruttura self-managed (Kafka su EC2, Elasticsearch su EC2) richiede strumentazione custom per ogni tecnologia.
• Questo approccio racconta il consumo proporzionale, non il costo effettivo.

È un'approssimazione ragionevole per la visibilità interna, ma non regge per una vera analisi del cost-to-serve.

L'attribuzione dei costi per cliente nelle architetture multi-tenant AWS è un problema risolto per i modelli dedicated-tenant e un problema irrisolto per default per l'infrastruttura condivisa. La toolchain FinOps standard (CUR, Cost Explorer, tagging) restituisce il costo per servizio e per team, non il costo per cliente.

Arrivarci implica una scelta: passare a un'architettura meno condivisa (alto costo operativo), investire in strumentazione a livello applicativo (incompleta per natura), oppure osservare direttamente il comportamento a runtime (copertura completa).

Se si adotta un modello di pricing basato sul consumo o si vogliono individuare gli account non redditizi su larga scala, gli approcci incompleti non portano al risultato. Se invece serve un'allocazione approssimativa per il reporting interno, il tagging unito a un po' di modellazione copre buona parte del percorso.

La maggior parte dei team finisce per accontentarsi di un modello di allocazione che sa essere utile come indicazione di massima, ma non davvero preciso.

In generale, gli strumenti FinOps sono costruiti attorno alle fatture cloud, non attorno al comportamento condiviso a runtime. Funziona, finché non serve un'attribuzione più profonda all'interno di sistemi fortemente condivisi.

A quel punto, il limite di solito non sta nei dati di fatturazione AWS, ma nella visibilità su come l'infrastruttura condivisa viene realmente consumata.

Attribute™ si concentra proprio su questo livello di attribuzione a runtime per gli ambienti multi-tenant.