Suivre les coûts par client dans une architecture AWS multi-tenant

AWS Cost Explorer et tous les outils fondés sur la facturation vous donnent les coûts par compte, région, service et tag. Cela fonctionne parfaitement pour les modèles à tenant dédié, où chaque client dispose de son propre compte ou namespace. Cela échoue dès qu'il s'agit d'infrastructure partagée.

Un cluster RDS unique qui sert 400 clients ne génère pas 400 lignes de facturation. Il en génère une seule. Un cluster Kafka utilisé par une douzaine d'équipes produit reste un unique centre de coût partagé. Un node pool EKS qui exécute des workloads mixtes est facturé comme du compute, pas comme client A : 142 k$, client B : 89 k$.

L'approche par tagging échoue ici pour trois raisons :

1. Les tags ne se propagent pas à travers les ressources partagées. Vous pouvez taguer une instance EC2 avec une équipe ou un service. Vous ne pouvez pas taguer une requête vers une base de données partagée.
2. Les tags exigent un effort d'engineering continu. Chaque nouvelle ressource, chaque nouveau service, chaque nouveau déploiement doit être tagué. Dans les organisations qui vont vite, la couverture se dégrade rapidement.
3. Les tags disent ce qu'est la ressource, pas comment elle a été utilisée. Une instance RDS taguée vous indique qu'elle relève du service payments. Elle ne vous dit pas que 60 % de sa charge provient d'un seul client ce mois-ci.

Le principe : plutôt que d'exploiter les exports de facturation ou d'ajouter de l'instrumentation applicative, on observe ce qui se passe réellement au niveau réseau et système : quels services appellent quelles bases de données, quels identifiants clients apparaissent dans quelles requêtes, quelle charge chaque client génère sur chaque ressource partagée.

La distinction est essentielle : les systèmes de facturation ne voient que des montants facturés. Les systèmes runtime, eux, voient la consommation réelle.

En pratique, c'est l'une des rares approches capables d'attribuer des systèmes partagés comme RDS, Kafka ou Elasticsearch à des clients individuels, sans modification applicative ni hygiène de tagging irréprochable.

Elle offre par ailleurs une attribution en temps réel là où les exports CUR sont différés, et couvre les infrastructures self-managed qui n'apparaissent jamais proprement dans les données de facturation AWS.

Le compromis : il faut un composant qui observe le trafic réseau et les appels système. Par le passé, collecter ce niveau de données runtime en production relevait du casse-tête opérationnel. eBPF a changé la donne. Les primitives qui alimentent des outils comme Cilium, Falco ou Pixie servent tout aussi bien à l'attribution des coûts au runtime. La différence : vous extrayez des signaux de consommation de ressources plutôt que des événements de sécurité ou d'observabilité.

Le principe : chaque client dispose d'un compte AWS ou d'un namespace Kubernetes dédié, avec une facturation isolée en conséquence.

Là où ça marche : secteurs à forte contrainte de conformité (santé, finance), contrats entreprise avec exigences d'isolation, clients suffisamment importants pour justifier économiquement une infrastructure dédiée.

Là où ça coince : le modèle ne passe pas à l'échelle sur des centaines de clients PME. Le coût opérationnel de la gestion de centaines de comptes AWS est significatif. La couverture des Reserved Instances se fragmente. Et il reste de toute façon des services partagés (pipelines de logs, infrastructure d'observabilité, data planes) en dehors des comptes par tenant.

Le principe : imposer des standards de tagging sur toutes les ressources. Utiliser des tags customer-id, team, service et environment. Récupérer les données de coût taguées via l'API Cost Explorer ou AWS Cost and Usage Reports (CUR). Bâtir une logique d'agrégation par-dessus.

Là où ça marche : architectures greenfield où les standards de tagging sont imposés dès le premier jour. Fonctionne raisonnablement bien pour le compute dédié (EC2, node groups EKS, Lambda), où la correspondance entre ressource et client est nette.

Là où ça coince :

• Tout s'effondre dès que plusieurs clients partagent les mêmes systèmes stateful. Un cluster RDS partagé ou un déploiement Kafka reste fondamentalement une facture unique pour de nombreux consommateurs.
• En pratique, la plupart des organisations matures ne parviennent pas à maintenir une couverture de tagging propre dans la durée. Les responsabilités changent, les services prolifèrent, les tags se dégradent.
• Les données CUR arrivent avec 24 à 48 heures de retard : vous êtes toujours dans le rétroviseur.
• Les ressources partagées (Kafka self-managed, Elasticsearch sur EC2) sont totalement invisibles pour les exports de facturation.

La plupart des équipes qui adoptent cette approche vivent avec des angles morts importants, qu'elles identifient et assument.

Le principe : instrumenter le code applicatif pour émettre des métriques par client : requêtes exécutées, octets lus/écrits, temps de compute consommé. Construire un modèle de coût qui rattache ces métriques aux dépenses AWS. Multiplier la consommation par le coût unitaire pour produire une estimation de coût par client.

Là où ça marche : équipes dotées d'une forte culture d'observabilité, applications dont la consommation de ressources est dominée par un petit nombre d'opérations mesurables, équipes pricing produit qui ont besoin d'une approximation.

Là où ça coince :

• La couverture d'instrumentation est incomplète par définition : vous mesurez ce que vous avez choisi de mesurer.
• L'infrastructure partagée (connection pooling, overhead de cluster, capacité inutilisée) ne se rattache à aucune opération spécifique.
• Les modèles de coût demandent une calibration continue à mesure que les prix évoluent.
• L'infrastructure self-managed (Kafka sur EC2, Elasticsearch sur EC2) exige une instrumentation sur mesure pour chaque technologie.
• Cette approche donne une consommation proportionnelle, pas un coût réel.

C'est une approximation acceptable pour de la visibilité interne, mais insuffisante pour une véritable analyse du cost-to-serve.

L'attribution des coûts par client dans les architectures AWS multi-tenant est un problème résolu pour les modèles à tenant dédié, et un problème sans solution native pour les infrastructures partagées. La chaîne d'outils FinOps standard (CUR, Cost Explorer, tagging) vous donne le coût par service et par équipe. Elle ne vous donne pas le coût par client.

Y parvenir suppose soit de basculer vers une architecture moins partagée (coût opérationnel élevé), soit d'investir dans l'instrumentation applicative (incomplète par nature), soit d'observer directement le comportement à l'exécution (couverture exhaustive).

Si vous exploitez un modèle de tarification à la consommation ou cherchez à identifier les comptes non rentables à grande échelle, les approches incomplètes ne vous mèneront pas au but. Si une répartition approximative pour du reporting interne suffit, le tagging assorti d'un peu de modélisation fait déjà l'essentiel du travail.

La plupart des équipes se contentent d'un modèle d'allocation qu'elles savent directionnellement utile, mais pas véritablement précis.

De manière générale, l'outillage FinOps se construit autour des factures cloud, pas autour du comportement runtime des systèmes partagés. Cela suffit jusqu'au jour où il faut une attribution plus fine à l'intérieur de systèmes fortement mutualisés.

À ce stade, la limite ne se situe généralement pas du côté des données de facturation AWS. Elle tient à la visibilité sur la façon dont l'infrastructure partagée est réellement consommée.

Attribute™ se concentre précisément sur cette couche d'attribution runtime pour les environnements multi-tenant.