Cloud-Kosten pro Feature, pro Kunde und pro Umgebung entstehen, indem bereits zugeordnete Kosten nach einer weiteren Dimension geschnitten werden: die Umgebung über Konten, Projekte oder einen Tag, das Feature über Tags, Labels oder Dienstgrenzen, der Kunde über eigene Ressourcen je Mandant oder einen gemessenen Verbrauch. Diese Sichten zeigen, was Produktion gegenüber Test kostet, was ein Feature im Betrieb kostet und was es kostet, einen Kunden zu bedienen. Sie liefern den Zähler für Stückkosten und die technische Bruttomarge und sind nur so genau wie ihr Mechanismus: exakt, wo eine Ressource genau einem Kunden, Feature oder einer Umgebung gehört, geschätzt, wo sie geteilt ist.
So funktioniert es
Jede Sicht ist ein weiteres Segment über denselben Abrechnungsdaten, neben Team und Kostenstelle (Segmente und Hierarchien); die drei unterscheiden sich im Mechanismus, der eine Position zuweist.
Umgebung
Produktion, Staging und Entwicklung lassen sich über die Struktur trennen. Ein eigenes Konto, eine eigene Subscription oder ein eigenes Projekt je Umgebung schreibt die Umgebung auf jede Position, vollständig, rückwirkend und ohne Tagging (Zuordnung über Konten, Subscriptions und Projekte). Wo sich Umgebungen ein Konto teilen, trägt ein Tag wie environment die Umgebung, in einem Kubernetes-Cluster ein Namespace je Umgebung. Exakt bleibt die Sicht, solange keine Ressource mehreren Umgebungen dient; Werkzeuge wie CI oder Monitoring, die alle Umgebungen bedienen, sind deren geteilte Kosten.
Feature
Ein Feature hat selten ein eigenes Konto. Sichtbar wird es über einen Tag oder ein Label an seinen Ressourcen (Tags und Labels) oder über eine Dienstgrenze: eine Funktion, eine Queue, ein Dienst oder ein Namespace, der nur diesem Feature dient (Kubernetes-Kostenzuordnung). Exakt ist das für Ressourcen, die nur das Feature nutzt. Teilt es sich eine Datenbank oder einen Cluster mit anderen, ist sein Anteil daran eine Schätzung über einen Treiber, etwa die Anfragen oder die Rechenzeit, die es dort verursacht.
Kunde oder Mandant
Wie genau Kosten je Kunde werden, hängt vom Mandantenmodell der Anwendung ab. Die AWS SaaS Lens unterscheidet Silo (eigene Ressourcen je Mandant), Pool (geteilte Ressourcen) und Bridge (eine Mischung je Dienst). Microsofts Leitfaden für mehrmandantenfähige Lösungen beschreibt die passenden Mechanismen. Dedizierte Ressourcen tragen einen Tag mit der Mandanten-ID, oder der Mandant hat ein eigenes Konto, eine eigene Subscription, Ressourcengruppe oder ein eigenes Projekt; die Kosten sind dann exakt. Teilen sich mehrere Mandanten eine Ressource, etwa einen Shard oder einen Deployment Stamp, empfiehlt der Leitfaden einen Tag mit der ID der Gruppe statt eines Tags je Mandant, da Tags je Ressource begrenzt sind, und eine getrennte Zuordnung der Mandanten zur Gruppe in einer Shard Map oder Nachschlagetabelle. Die Kosten der Gruppe sind exakt, der Anteil des einzelnen Mandanten nicht.
Für vollständig geteilte Ressourcen misst die Anwendung den Verbrauch je Mandant. Microsoft nennt Anfragen je Mandant (die gleich aufwendige Anfragen unterstellen), eine Schlüsseltransaktion wie erstellte Dokumente und indikative Messwerte wie gespeicherte Daten; die AWS SaaS Lens beschreibt, aus solchen Messwerten einen Verbrauchsanteil je Mandant zu bilden und ihn auf die Infrastrukturkosten der Rechnung anzuwenden. In Kubernetes legt der GKE-Leitfaden zur Mehrmandantenfähigkeit bei SaaS-Anbietern jede Kundeninstanz in einen eigenen Namespace; die Kosten des Namespace werden so zu Kosten des Kunden, die Reste des Clusters zu geteilten Kosten.
Die Rechnung
Kosten je Kunde oder je Feature sind die direkten Kosten (Ressourcen, die nur ihm gehören) plus ein Anteil an den geteilten Kosten, verteilt nach einem benannten Treiber (Geteilte Kosten). Der Treiber stammt aus derselben Periode wie die Kosten. Was weder direkte Zuordnung noch Treiber erfasst, bleibt als nicht zugeordneter Rest sichtbar, und alle Kunden plus Rest ergeben die Kosten, von denen die Rechnung ausging.
| Sicht | Mechanismus | Exakt oder geschätzt | Benötigte Daten | Falle |
|---|---|---|---|---|
| Umgebung | Konto, Subscription oder Projekt je Umgebung; Tag; Namespace | exakt, solange nichts geteilt ist | Kontenliste oder Tag | geteilte Werkzeuge wie CI und Monitoring |
| Feature | Tag oder Label; eigener Dienst oder Namespace | exakt für eigene Ressourcen, sonst geschätzt | Tag, Dienstgrenze, Treiber aus der Anwendung | gemeinsame Datenbank ohne Treiber |
| Kunde, dedizierte Ressourcen | Konto, Projekt, Ressourcengruppe oder Tag mit Mandanten-ID | exakt | Mandanten-ID an Konto, Ressourcengruppe oder Ressource | die geteilte Plattform bleibt geteilt |
| Kunde, geteilte Ressourcen | Tag der Gruppe plus Zuordnungstabelle; Verbrauchsmessung | geschätzt | Messwert je Mandant aus der Anwendung | ungleich teure Anfragen, Stichproben in der Telemetrie |
Was es für Ihre Kosten bedeutet
In den Abrechnungsdaten erscheinen Umgebung und Feature als Konto oder als Tag-Spalte, der Kunde nur bei dedizierten Ressourcen. Für geteilte Ressourcen steht der Kunde nie in den Daten des Anbieters; die Kosten je Kunde entstehen erst, wenn die Abrechnungsdaten mit den Messwerten der Anwendung verknüpft werden. Die nativen Werkzeuge reichen dafür nur teilweise: AWS Cost Categories fassen Positionen nach Konto, Tag und weiteren Dimensionen zu einem Wert je Zeile zusammen; die Kostenzuordnungsregeln von Azure verteilen geteilte Kosten zwischen Subscriptions, Ressourcengruppen oder Tags, nur für bestimmte Abrechnungskonten und ohne Käufe von Reservierungen oder Savings Plans. Bei Google Cloud geschieht die Verknüpfung in Abfragen über den BigQuery-Export.
Die Umgebungssicht zeigt, was alles außerhalb der Produktion kostet, die Featuresicht stellt Betriebskosten neben Roadmap und Architektur, und die Kundensicht zeigt die Cost to Serve (Kosten der Leistungserbringung) je Mandant und Preisstufe, auch Mandanten, die bei Pauschalpreisen deutlich mehr verbrauchen als andere. Die FinOps Foundation zählt Kosten je Mandant und Cost to Serve in ihrer Capability Unit Economics zu den geschäftlichen Kennzahlen und hält fest, dass viele Organisationen aus dem Verlauf einer solchen Zahl innerhalb eines FinOps Scope mehr ablesen als aus einem Vergleich über nicht verwandte Produkte hinweg. Wie ein Produkt bepreist wird, ist eine eigene Frage; diese Zahlen sind dafür nur eine Eingabe.
Eine Zahl aus einem Treiber ist eine Schätzung und wird als solche geführt: mit Treiber, Periode und dem Anteil, der direkt zugeordnet war. Microsofts Leitfaden warnt davor, die Messung genauer zu bauen als nötig und Kosten in Echtzeit messen zu wollen; die AWS SaaS Lens hält es für lohnender, Verbrauchsdaten nur dort zu erheben, wo sich die Kosten konzentrieren. Aussagekraft gewinnt die Zahl im Zeitraumvergleich.
Wo es schiefgeht
- Ein Mandanten-Tag an einer geteilten Ressource. Symptom: Eine Datenbank, die mehrere Mandanten bedient, erscheint vollständig bei einem von ihnen. Ursache: Ein Tag ordnet die ganze Ressource einem Wert zu; an eine geteilte Ressource gehört die ID der Gruppe, die Aufteilung in eine eigene Tabelle.
- Monitoring-Daten als Verteilschlüssel. Symptom: Die Anteile der Mandanten schwanken, ohne dass sich ihre Nutzung ändert. Ursache: Monitoring-Werkzeuge erfassen Telemetrie mit Stichproben und sind nach Microsofts Leitfaden nicht für genaue Messung gebaut.
- Umgebungen teilen sich ein Konto. Symptom: Die Produktionskosten enthalten Test- und Staging-Ressourcen. Ursache: Mehrere Umgebungen laufen im selben Konto oder Cluster, ohne Tag oder Namespace je Umgebung.
- Der Rest verschwindet in den Kunden. Symptom: Die Kunden ergeben genau die Rechnung, und die Kosten je Kunde steigen bei allen gleichzeitig. Ursache: Der nicht zugeordnete Rest wurde über den Treiber mitverteilt.
Quellen
Gelesen am 2026-10-16. FinOps Foundation Capability Unit Economics (CC BY 4.0); AWS SaaS Lens: Silo, Pool, and Bridge Models, SaaS Lens: Expenditure awareness und Kosten mit AWS Cost Categories ordnen; Microsoft Kostenmanagement und Kostenzuordnung in mehrmandantenfähigen Lösungen, Verbrauch je Mandant messen und Einführung in die Kostenzuordnung; Google Cluster-Mehrmandantenfähigkeit.