Der komplette Guide zur Cloud- und KI-Kostenattribution

Situation	Reicht der Billing-Export?
Einfache Single-Tenant-Infrastruktur	Ja
Kleines Team, ein Cloud-Account	Ja
Kubernetes-Microservices	Meistens nein
Multi-Tenant-SaaS-Produkt	Nein
Gemeinsam genutztes RDS, Kafka oder Elasticsearch	Nein
Zuordnung von KI-Inferenzkosten nach Kunde oder Feature	Nein
Analyse der Kundenmargen	Nein
Selbst betriebene Infrastruktur (auf EC2 gehostete Datensysteme)	Nein
Attribution von NAT-Gateway und Data Transfer	Nein

Wenn Ihre Umgebung eher der unteren Hälfte dieser Tabelle entspricht, sind Billing-Exports bestenfalls ein Ausgangspunkt. Ein Werkzeug zur Kostenoptimierung sind sie nicht. Für Teams, die KI-Features betreiben, ist diese Lücke besonders schmerzhaft: Token-Kosten sind nur ein Teil der KI-Kostenlandschaft. Vektordatenbanken, Orchestrierungsschichten, Egress und selbst betriebene Infrastruktur rund um den Modellaufruf machen regelmäßig 40 bis 60 Prozent der gesamten Feature-Kosten aus. Tools, die nur die Token-Rechnung auswerten, übersehen den Großteil.

Cloud-Billing wurde für ein statisches Modell entwickelt: Ressource bereitstellen, taggen, Tag am Monatsende auslesen.

Kubernetes hat jede Annahme, auf der dieses Modell beruht, ausgehebelt. Pods sind kurzlebig. Services teilen sich Infrastruktur über Team- und Tenant-Grenzen hinweg. Ein einzelner Kundenrequest läuft durch mehrere Services, bevor eine Antwort zurückgeht. Das Ergebnis: Kein Tag erfasst, wer was verbraucht hat – nur, wem die Ressource gehört. Und Ownership ist eben nicht gleich Consumption.

Die meisten Kubernetes-Kostenmonitoring-Tools reagieren darauf, indem sie auf Cluster-Ebene messen: CPU-Allokation, Memory Requests, Pod-Stunden. Das liefert nützlichen Kontext, aber keine Kostenattribution. RDS, Kafka, Snowflake und Data Transfer sind neben dem Cluster oft ein erheblicher und schlecht zugeordneter Kostentreiber. Tools, die auf Node- und Pod-Ebene aufhören, lassen den Großteil der Rechnung unattribuiert.

Vier Konsequenzen sind absehbar:

• Tagging wird zum Dauerprojekt. Tags erfassen Ownership. Den Verbrauch gemeinsam genutzter Ressourcen können sie nicht zuordnen. Das Projekt zieht sich über Monate – und ist nie ganz fertig.
• Geteilte Kosten werden nach Bauchgefühl verteilt. Statische Prozentsätze, gleichmäßige Splits. Im Spreadsheet vertretbar. Präzise ist das nicht.
• Attribution auf Kundenebene fehlt. Die Gesamtausgaben sind sichtbar. Die Kosten pro Tenant nicht. Profitable und unprofitable Accounts sehen identisch aus.
• Die Daten kommen zu spät. Der Billing-Export schließt zum Monatsende. Der Waste ist da längst entstanden.

Runtime-Attribution setzt an einer ganz anderen Datenquelle an: an dem, was gerade tatsächlich im System passiert.

Attribute™ rollt einen eBPF-Sensor auf der Compute-Infrastruktur aus – EKS-Nodes, ECS-Tasks, EC2-Instanzen, Auto Scaling Groups. eBPF (extended Berkeley Packet Filter) ist eine Linux-Kernel-Technologie, mit der sich Systemaktivität sicher und sandboxed auf Kernel-Ebene beobachten lässt. Der Sensor inspiziert Netzwerkpakete rein lesend, ohne Performance-Overhead und ohne Änderungen am Anwendungscode.

Was der Sensor beobachtet:

• Jeden Netzwerkaufruf zwischen Services
• Welcher Microservice welche Datenbank in welcher Frequenz aufruft
• Wie gemeinsam genutzte Infrastruktur tatsächlich beansprucht wird
• Welche KI-API-Endpunkte von welchem Workload mit welchem Token-Volumen aufgerufen werden – und welchem Kunden, Feature oder Agent das zugeordnet ist
• HTTP-Header mit Kundenkennungen
• Data-Transfer-Ziele und -Volumina

Aus diesen Beobachtungen baut Attribute™ einen Live-Service-Dependency-Graph. Er weiß, welche Services in welcher Intensität und in welchen Verhältnissen von welchen Ressourcen abhängen. Dieser Graph ist das Attributionsmodell.

Verursacht eine gemeinsam genutzte RDS-Instanz Kosten, greift das Modell nicht auf eine statische Regel zurück. Es betrachtet die tatsächliche Verteilung der Datenbankabfragen über die Services im entsprechenden Zeitraum und ordnet die Kosten proportional zum realen Verbrauch zu.

Neue Services werden automatisch erkannt, sobald sie auftauchen. Beziehungen aktualisieren sich mit jedem Deployment. Kein statischer Service-Katalog. Keine manuelle Neukonfiguration.

Case Study: Island

Die Ausgangslage: Island baut die Kategorie des Enterprise-Browsers auf – bei einer Bewertung von 5 Mrd. USD und mit Hunderten von Enterprise-Kunden. Die AWS-Umgebung nutzt gemeinsam genutztes EKS, RDS, DynamoDB sowie erheblichen AZ-zu-AZ-Data-Transfer. Tagging war keine Option – in einer Multi-Tenant-Architektur lässt sich ein Kunde nicht taggen.

Vorher: Keine Sicht auf die tatsächlichen Kosten pro Kunde oder pro Feature. Keine Möglichkeit, Pricing, Wachstumsmodelle oder GTM-Entscheidungen mit echten Kostendaten zu unterlegen. Native Cloud-Tools und Drittanbieter-Plattformen konnten Rechnungen und Charts anzeigen. Was jeder Kunde tatsächlich kostet, konnten sie nicht beantworten.

Nachher: Attribute™ lieferte innerhalb weniger Tage präzise Kosten pro Kunde und pro Feature. Ohne Tagging, ohne Instrumentierung, ohne Engineering-Tickets.

Operative Veränderung: Engineering, Produkt und GTM arbeiten heute mit einer gemeinsamen Kostenquelle. Pricing- und Wachstumsentscheidungen basieren auf realen Verbrauchsdaten – nicht auf Schätzungen.

"In einer Multi-Tenant-Umgebung lässt sich kein Kunde taggen. Attribute™ zeigt uns endlich, was jeder Kunde kostet und was diese Kosten treibt.",

– Omri Cohen, Director of Engineering Platform, Island

Mehr lesen? Hier klicken, um zu erfahren, wie eine führende Work-Management-Plattform 360 unprofitable Accounts identifiziert hat, oder hier, um zu lesen, wie ein Security-Unternehmen das Reporting für Finance und Engineering entzerrt hat.

Unit Economics brauchen ein Kostenmodell, das zur tatsächlichen Einheit passt. Bei einem SaaS-Unternehmen ist diese Einheit meist der Kunde.

Diese Frage lässt sich aus Billing-Exports nicht beantworten. Billing zeigt Ressourcenkosten. Es zeigt nicht, welche Kunden diese Ressourcen in welchem Umfang genutzt haben.

Die Customer-Attribution-Schicht von Attribute™ ordnet beobachtete Runtime-Aktivität Kundenkennungen zu – aus HTTP-Headern, Workload-Labels oder Namenskonventionen in Datenbanken oder Queue-Namen. Steht das einmal, wird jedes Kostenereignis im Modell dem Kunden zugeordnet, der es ausgelöst hat.

In Verbindung mit Umsatzdaten entsteht daraus eine P&L auf Kundenebene: welche Accounts profitabel sind, welche nicht und in welchem Ausmaß.

Was aus dieser Sicht folgt:

• Accounts mit negativer Marge erkennen, bevor sich Verluste anhäufen
• KI-Features mit aus dem Ruder laufenden Kosten aufdecken, bevor der Billing-Zyklus endet
• Platform-Teams belastbare Zahlen für das Chargeback gemeinsam genutzter Infrastruktur an die Hand geben
• Enterprise-Verträge kalkulieren auf Basis tatsächlicher Nutzung statt auf Annahmen
• Architektur-Investitionen mit echten Vorher-nachher-Zahlen begründen
• Der monatlichen Debatte zwischen Finance und Engineering über die Allokationsmethodik ein Ende setzen

Time to Value: Der Sensor wird auf Kubernetes per DaemonSet ausgerollt. Die initiale Workload-Discovery ist innerhalb weniger Stunden abgeschlossen. Belastbare Kostenattribution steht innerhalb weniger Tage zur Verfügung. Kein Tagging-Projekt erforderlich.

Performance-Overhead: Der eBPF-Sensor arbeitet rein lesend und ist auf Kernel-Ebene sandboxed. Er fängt Traffic weder ab noch verändert er ihn. Der Compute-Overhead ist vernachlässigbar.

Integrationen: Attribute™ wird auf der Compute-Infrastruktur installiert (EKS, ECS, EC2) und beobachtet Traffic von der Anwendungsschicht zu anderen Cloud-Ressourcen – inklusive Drittanbieter-SaaS wie MongoDB Atlas, Snowflake, OpenAI und weiteren. Eine Instrumentierung auf Anwendungsebene ist nicht nötig.

Ersetzt das Kubecost oder CloudHealth? Für SaaS-Unternehmen, deren Kostenfragen über das Cluster-Level-Reporting hinausgehen: ja. Attribute™ geht weiter bei der Attribution gemeinsam genutzter Ressourcen, bei Cost-to-Serve auf Kundenebene, bei der Abdeckung selbst betriebener Infrastruktur und bei der vollständigen Sicht auf die KI-Kostenlandschaft – inklusive Token-Attribution nach Kunde, Feature oder Agent und den umliegenden Infrastrukturkosten, die diese Tools nicht sehen.

Historische Daten: Die Cloud-Billing-Historie wird beim Setup eingelesen. Für Teams, die Chargeback-Ergebnisse vor dem Sensor-Deployment brauchen, kann Attribute™ Reports auch aus den vom Kunden bereitgestellten Billing-Exports ohne Sensor erzeugen.

Unterstützte Umgebungen: AWS, GCP, Azure. Kubernetes (EKS, GKE, AKS), ECS, EC2. Snowflake, MongoDB Atlas, OpenAI, Anthropic, Amazon Bedrock, Azure OpenAI, Vertex AI. Selbst betriebenes Kafka (inklusive Topic-Granularität), Elasticsearch, RabbitMQ.

Sicherheit: PII, Credentials, Secrets, API-Keys und Cookies werden entfernt, bevor Daten die Kundenumgebung verlassen. Übertragen werden nur minimale Events – via verschlüsseltem OpenTelemetry, JWT-authentifiziert, TLS-geschützt. Rohpakete werden nie übertragen. Kunden können die Telemetrie optional über einen eigenen OpenTelemetry-Endpunkt leiten und so volle Auditfähigkeit sicherstellen.

Billing-basierte Tools fragen, was in Rechnung gestellt wurde. Runtime-Attribution fragt, was im System tatsächlich passiert ist – und wer es ausgelöst hat.

Für Buyer-Teams in der Plattform-Evaluierung trennen fünf Fragen die Tools, die die entscheidenden Antworten liefern können, von jenen, die es nicht tun:

1. Funktioniert es vom ersten Tag an ohne Tags?
2. Kann es Kosten für gemeinsam genutzte Ressourcen auf Basis des beobachteten Verbrauchs allokieren – statt nach statischen Regeln?
3. Kann es Kosten in einem Multi-Tenant-System einzelnen Kunden zuordnen?
4. Erfasst es selbst betriebene Infrastruktur und externe KI-Ausgaben?
5. Liefert es Kostensignale während des Billing-Zyklus – und nicht erst nach dessen Abschluss?

Für Teams mit nennenswerten KI-Ausgaben kommt eine sechste hinzu: Kann es Token-Kosten einem konkreten Kunden, Feature oder Agent zuordnen – nicht nur einem API-Key? Billing-basierte Tools beantworten einige dieser Fragen teilweise, für bestimmte Umgebungen und mit erheblichem Setup-Aufwand. Runtime-Attribution beantwortet sie ab dem Deployment alle.