Die meisten SaaS-Infrastrukturen sind standardmäßig multi-tenant. Ein AWS-Konto, ein EKS-Cluster, eine RDS-Instanz – geteilt von Hunderten oder Tausenden Kunden. Das hält die Auslastung hoch, macht es aber nahezu unmöglich, die Frage zu beantworten: "Was kostet es tatsächlich, Kunde X zu betreiben?"
Diese Frage taucht ständig auf, und die Antworten reichen meist von "Wir taggen, was geht, und schätzen den Rest" bis "Wir haben aufgegeben und rechnen mit Durchschnittskosten pro Seat." Beides reicht nicht, wenn Ihnen Unit Economics wichtig sind.
Hier ist ein praxisnaher Überblick der Ansätze, ihrer Trade-offs und wo sie jeweils an Grenzen stoßen.
Das Kernproblem: Geteilte Ressourcen lassen sich nicht sauber taggen
AWS Cost Explorer und jedes abrechnungsbasierte Tool liefern Kosten nach Konto, Region, Service und Tag. Für Dedicated-Tenant-Modelle, bei denen jeder Kunde ein eigenes Konto oder einen eigenen Namespace bekommt, funktioniert das gut. Bei geteilter Infrastruktur versagt es.
Ein einzelner RDS-Cluster, der 400 Kunden bedient, hat keine 400 Kostenpositionen. Er hat eine. Ein Kafka-Cluster, den ein Dutzend Produktteams nutzt, erscheint weiterhin als eine einzige gemeinsame Kostenstelle. Ein EKS Node Pool mit gemischten Workloads wird als Compute abgerechnet, nicht als "Kunde A: 142.000 $, Kunde B: 89.000 $".
Der Tagging-Ansatz scheitert hier auf drei Ebenen:
- Tags werden nicht durch geteilte Ressourcen weitergereicht. Sie können eine EC2-Instanz einem Team oder Service zuordnen. Eine Abfrage gegen eine geteilte Datenbank können Sie nicht taggen.
- Tags erfordern kontinuierlichen Engineering-Aufwand. Jede neue Ressource, jeder neue Service, jedes neue Deployment braucht ein Tag. In schnelllebigen Organisationen bröckelt die Abdeckung rasch.
- Tags sagen Ihnen, was die Ressource ist – nicht, wie sie genutzt wurde. Eine getaggte RDS-Instanz sagt Ihnen, dass sie zum Service "payments" gehört. Sie sagt Ihnen aber nicht, dass 60 % der Last in diesem Monat von einem einzigen Kunden kamen.
Ansatz 1: Analyse des Runtime-Traffics (unsere Empfehlung)
So funktioniert es: Statt Billing-Exporte auszuwerten oder die Anwendung zu instrumentieren, beobachten Sie, was tatsächlich auf Netzwerk- und Systemebene passiert: welche Services welche Datenbanken aufrufen, welche Kunden-IDs in welchen Queries auftauchen und wie viel Last jeder Kunde auf jeder geteilten Ressource erzeugt.
Der entscheidende Unterschied: Abrechnungssysteme sehen nur Gebühren. Runtime-Systeme sehen den tatsächlichen Verbrauch.
In der Praxis ist das einer der wenigen Ansätze, mit denen sich geteilte Systeme wie RDS, Kafka oder Elasticsearch einzelnen Kunden zuordnen lassen – ohne Anwendungsänderungen oder perfekte Tagging-Hygiene.
Zudem liefert er Attribution in Echtzeit statt verzögerter CUR-Exporte und deckt selbst verwaltete Infrastruktur ab, die in AWS-Billing-Daten nie sauber auftaucht.
Der Trade-off: Es braucht eine Komponente, die Netzwerkverkehr und Systemaufrufe beobachtet. Früher war es operativ mühsam, solche Runtime-Daten in Produktion zu sammeln. eBPF hat das geändert. Dieselben Primitive, auf denen Tools wie Cilium, Falco und Pixie basieren, lassen sich auch für Runtime-Kostenattribution nutzen. Der Unterschied: Sie extrahieren Signale zum Ressourcenverbrauch statt Security- oder Observability-Events.
Ansatz 2: Ein Konto pro Tenant (oder ein Namespace pro Tenant)
So funktioniert es: Jeder Kunde bekommt ein dediziertes AWS-Konto oder einen Kubernetes-Namespace, mit entsprechend isolierter Abrechnung.
Wo es funktioniert: Stark regulierte Branchen (Healthcare, Finance), Enterprise-Verträge mit vertraglichen Isolationsanforderungen, Kunden, die groß genug sind, um dedizierte Infrastruktur wirtschaftlich zu rechtfertigen.
Wo es scheitert: Für Hunderte SMB-Kunden skaliert es nicht. Der operative Aufwand, Hunderte AWS-Konten zu verwalten, ist erheblich. Die Abdeckung durch Reserved Instances zersplittert. Und Sie haben weiterhin geteilte Services (Logging-Pipelines, Observability-Infrastruktur, Data Planes), die außerhalb der Tenant-Konten liegen.
Ansatz 3: Alles taggen und im Cost Explorer aggregieren
So funktioniert es: Setzen Sie Tagging-Standards für alle Ressourcen durch. Nutzen Sie Tags für customer-id, team, service und environment. Ziehen Sie die getaggten Kostendaten über die Cost Explorer API oder AWS Cost and Usage Reports (CUR) und bauen Sie darauf eine Aggregationslogik auf.
Wo es funktioniert: Greenfield-Architekturen, in denen Tagging-Standards von Tag eins an durchgesetzt werden. Funktioniert einigermaßen gut für dediziertes Compute (EC2, EKS Node Groups, Lambda), wo das Mapping zwischen Ressource und Kunde eindeutig ist.
Wo es scheitert:
- Sobald mehrere Kunden dieselben Stateful-Systeme teilen, fällt der Ansatz auseinander. Ein geteilter RDS-Cluster oder ein Kafka-Deployment hat prinzipbedingt eine Rechnung und viele Nutzer.
- In der Praxis halten die meisten gewachsenen Organisationen eine saubere Tag-Abdeckung nie lange durch. Zuständigkeiten wechseln, Services vermehren sich, und Tags verfallen.
- CUR-Daten kommen mit 24–48 Stunden Verzögerung – Sie blicken immer nach hinten.
- Geteilte Ressourcen (selbst verwaltetes Kafka, Elasticsearch auf EC2) sind für Billing-Exporte komplett unsichtbar.
Die meisten Teams, die diesen Weg gehen, haben erhebliche blinde Flecken, die sie kennen und in Kauf nehmen.
Ansatz 4: Instrumentierung auf Anwendungsebene
So funktioniert es: Instrumentieren Sie Ihren Anwendungscode so, dass er Metriken pro Kunde ausgibt: ausgeführte Queries, gelesene/geschriebene Bytes, verbrauchte Rechenzeit. Bauen Sie ein Kostenmodell, das diese Metriken auf AWS-Ausgaben abbildet. Multiplizieren Sie den Metrikverbrauch mit Stückkosten, um eine Kostenschätzung pro Kunde zu erhalten.
Wo es funktioniert: Teams mit ausgeprägter Observability-Kultur, Anwendungen, deren Ressourcenverbrauch von wenigen messbaren Operationen dominiert wird, Product-Pricing-Teams, die einen Näherungswert brauchen.
Wo es scheitert:
- Die Instrumentierung ist per Definition unvollständig. Sie messen nur das, was Sie zu messen entschieden haben.
- Geteilte Infrastruktur (Connection Pooling, Cluster-Overhead, Leerlaufkapazität) lässt sich keiner konkreten Operation zuordnen.
- Kostenmodelle müssen laufend nachjustiert werden, wenn sich Preise ändern.
- Selbst verwaltete Infrastruktur (Kafka auf EC2, Elasticsearch auf EC2) erfordert für jede Technologie eigene Instrumentierung.
- Dieser Ansatz zeigt Ihnen den proportionalen Verbrauch – nicht die tatsächlichen Kosten.
Für interne Transparenz ist das eine vernünftige Näherung, für eine echte Cost-to-Serve-Analyse taugt es nicht.
Fazit
Kostenattribution pro Kunde in Multi-Tenant-AWS-Architekturen ist für Dedicated-Tenant-Modelle ein gelöstes Problem – und für geteilte Infrastruktur ein standardmäßig ungelöstes. Der übliche FinOps-Toolstack (CUR, Cost Explorer, Tagging) liefert Ihnen Kosten nach Service und Team. Die Kosten pro Kunde liefert er nicht.
Dorthin zu kommen, erfordert entweder den Wechsel zu einer weniger geteilten Architektur (hohe Ops-Kosten), Investitionen in Instrumentierung auf Anwendungsebene (naturgemäß unvollständig) oder die direkte Beobachtung des Laufzeitverhaltens (umfassende Abdeckung).
Wer ein verbrauchsbasiertes Preismodell betreibt oder in großem Maßstab unprofitable Accounts identifizieren will, kommt mit den unvollständigen Ansätzen nicht ans Ziel. Wer eine grobe Zuordnung fürs interne Reporting braucht, kommt mit Tagging plus etwas Modellierung schon recht weit.
Die meisten Teams begnügen sich mit einem Zuordnungsmodell, von dem sie wissen, dass es die Richtung richtig anzeigt, aber nicht wirklich präzise ist.
FinOps-Tooling ist generell rund um Cloud-Rechnungen gebaut, nicht rund um geteiltes Laufzeitverhalten. Das reicht so lange, bis Sie tiefere Attribution innerhalb stark geteilter Systeme brauchen.
An diesem Punkt liegt die Grenze meist nicht an den AWS-Billing-Daten, sondern an der Sichtbarkeit dafür, wie geteilte Infrastruktur tatsächlich verbraucht wird.
Attribute™ konzentriert sich genau auf diese Runtime-Attributionsebene für Multi-Tenant-Umgebungen.