Segmente und Hierarchien der Kostenzuordnung

Eine Kostenhierarchie in der Cloud fasst Segmente stufenweise zusammen, etwa Teams zu Abteilungen und Abteilungen zu Geschäftsbereichen. Ein Segment ist eine benannte Gruppe von Kostenpositionen, die die Kostenzuordnung aus Konten, Tags oder Regeln bildet, und jede Position gehört je Dimension genau einem Segment. Deshalb ergibt jede Dimension für sich wieder die Rechnung, und mehrere Dimensionen wie Produkt, Team, Umgebung oder Region bestehen nebeneinander über denselben Daten. Geschäftsführung, Finance und Teams lesen so verschiedene Schnitte derselben Rechnungssumme.

So funktioniert es

Dimensionen und Werte

Eine Dimension ist eine Frage an jede Position, etwa die, zu welchem Produkt sie gehört. Ihre Werte sind die Segmente, ergänzt um einen Restwert für alles, was keine Bedingung erfüllt. Zwei Regeln sorgen dafür, dass eine Dimension in der Summe aufgeht. Jede Position bekommt genau einen Wert, damit nichts doppelt zählt, und der Rest ist ein eigener Wert, damit nichts verschwindet. Mehrere Dimensionen stören einander nicht: Dieselbe Position gehört zugleich zu einem Produkt, einem Team und einer Umgebung. Die Capability Allocation der FinOps Foundation beschreibt dasselbe: Finance, Engineering und Betrieb lesen dieselben Kostendaten jeweils in einer eigenen Aufteilung.

Hierarchien

Eine Hierarchie verdichtet die Werte einer Dimension zu den Werten einer höheren, das Team zur Abteilung, die Abteilung zum Geschäftsbereich. Sie geht in der Summe auf, solange jeder Knoten genau einen Elternknoten hat.

Eine Umorganisation ändert die Hierarchie und wirft die Frage auf, welche Monate das betrifft. Gilt die neue Zuordnung rückwirkend, bleiben Zeitreihen vergleichbar, aber frühere Berichte ändern ihre Zahlen. Gilt sie ab einem Stichtag, stimmen frühere Berichte, aber die Reihe springt. Beides ist vertretbar, solange die Zuordnung ein Gültigkeitsdatum trägt. Die Provider verhalten sich hier verschieden: Google hält die Hierarchie eines Projekts in project.ancestry_numbers so fest, wie sie zum Zeitpunkt der Nutzung war, AWS wendet geänderte Cost-Category-Regeln ab Beginn des laufenden Monats an oder, wenn ein früherer Monat als Beginn gewählt wird, rückwirkend ab diesem Monat; für den Cost and Usage Report dokumentiert AWS ein Backfill über einen Support-Fall. Für den Zeitraumvergleich bestimmt diese Entscheidung, ob eine Reihe vergleichbar bleibt.

AWS

AWS Cost Categories sind die eingebaute Segmentierung. Eine Cost Category ist ein Schlüssel, ihre Werte sind Segmente, und AWS hängt das Paar an jede Kostenposition, die eine Regel oder der Standardwert trifft. Eine reguläre Regel setzt einen festen Wert über Bedingungen auf Dimensionen wie Konto, Dienst, Region, Charge Type, Tag oder eine andere Cost Category; eine Regel vom Typ Inherited Value übernimmt den Wert dynamisch aus einem Tag-Schlüssel oder dem Kontonamen. Die Regeln werden der Reihe nach geprüft, die erste passende entscheidet, und ein optionaler Standardwert nimmt alles auf, was keine Regel trifft. Hierarchien entstehen, wenn die Regeln einer Cost Category die Werte einer anderen verwenden, etwa eine Kategorie für Geschäftsbereiche, die Werte einer Team-Kategorie zusammenfasst.

Nach dem Anlegen oder Ändern kann es bis zu 24 Stunden dauern, bis die Werte in Cost Explorer, AWS Budgets, dem Cost and Usage Report und Cost Anomaly Detection stehen. Im CUR 2.0 liegen sie in der Map-Spalte cost_category, und ein Schlüssel erscheint dort nur auf Positionen, für die ein Wert gilt. Cost Categories legt das Management-Konto an oder ein einzelnes Konto ohne Organisation: bis zu 50 je Management-Konto, jede mit bis zu 100 Regeln in der Konsole oder 500 über die API (AWS Cost Explorer und AWS Budgets).

Azure

Azure bildet Segmente aus dem Ressourcenbaum und aus Tags. Der Baum besteht aus Management Groups über Subscriptions und Ressourcengruppen, bis zu sechs Ebenen unter der Root Management Group. Er verdichtet allerdings nur nutzungsbasierte Kosten und wird in Cost Management für Subscriptions unter einem Microsoft Customer Agreement derzeit nicht unterstützt. Eine Dimension wird in der Kostenanalyse zur gespeicherten Ansicht: Sie hält Filter, Gruppierung, Granularität und Diagrammtyp fest, gilt nur in dem Scope, in dem sie gespeichert wurde, und speichert keine Daten. Möglich sind bis zu 100 private Ansichten je Nutzer über alle Scopes und bis zu 100 geteilte Ansichten je Scope, sichtbar für alle mit mindestens Cost Management Reader. Kostenzuordnungsregeln, die Kosten zwischen Subscriptions, Ressourcengruppen oder Tags verschieben, behandelt Virtuelle Tags und Zuordnungsregeln.

Google Cloud

Bei Google Cloud ist der eingebaute Baum die Ressourcenhierarchie aus Organisation, Ordnern bis zehn Ebenen tief und Projekten. Im Export steht er in project.ancestors, in den Cloud-Billing-Berichten als Gruppierung Project hierarchy. Weitere Dimensionen kommen aus Labels: Die Berichte gruppieren nach einem Label-Schlüssel, allerdings nicht nach Labels am Projekt, und fassen Kosten ohne diesen Schlüssel als „Charges for other usage“ zusammen. Bei Google Cloud lassen sich Segmente aus mehreren Bedingungen als Abfragen auf den BigQuery-Export bilden.

Die drei Provider nebeneinander

Was es für Ihre Kosten bedeutet

Jede Dimension wird zu einem Kostenbericht oder Dashboard mit derselben Summe: je Geschäftsbereich für die Geschäftsführung, je Kostenstelle für Finance, je Produkt und Umgebung für die Teams. Weil jede Dimension die ganze Rechnung abbildet, lassen sich die Berichte gegeneinander prüfen, und der Restwert zeigt in jedem, wie viel noch keinem Segment gehört. Budgets, Zeitraumvergleiche und Stückkosten setzen auf einem Segment auf und erben seine Qualität. Die Verbindung von Team und Kostenstelle, die Finance braucht, beschreibt Kostenstellen und Verantwortung im Team.

Segmente beschreiben Kosten und verschieben sie nie: Rechnung, Abrechnungskonto und Zahler bleiben, wie sie sind. Die Container darunter liefert die Zuordnung über Konten, Subscriptions und Projekte, die Werte innerhalb der Container liefern Tags und Labels oder Regeln.

Wo es schiefgeht

• Eine Position in zwei Segmenten. Symptom: Die Summe über alle Teams liegt über der Rechnung. Ursache: Bedingungen überschneiden sich ohne feste Reihenfolge; AWS Cost Categories vergeben den Wert der ersten passenden Regel, eine selbst geschriebene Abfrage tut das nur, wenn sie so gebaut ist.
• Knoten mit zwei Eltern. Symptom: Ein gemeinsames Team erscheint unter zwei Abteilungen, und die Geschäftsbereiche ergeben zusammen mehr als die Rechnung. Ursache: Die Hierarchie lässt zwei Eltern zu, wo ein geteiltes Team einen eigenen Knoten und eine Verteilungsregel braucht.
• Kein Restwert. Symptom: Eine Auswertung über die Werte einer Cost Category ergibt weniger als die Rechnung. Ursache: Ohne Standardwert tragen Positionen, die keine Regel trifft, keinen Wert; im CUR 2.0 fehlt der Schlüssel dann in cost_category, und eine Abfrage über die Werte lässt sie stillschweigend aus.
• Umorganisation ohne Gültigkeitsdatum. Symptom: Die Zahlen eines abgeschlossenen Quartals ändern sich nachträglich, oder die Reihe einer Abteilung springt im Monat der Umorganisation. Ursache: Die Zuordnung wurde ohne Gültigkeitsdatum geändert und ohne Entscheidung, ob sie rückwirkend gilt.

Quellen

Gelesen am 2026-10-16. FinOps Foundation Capability Allocation (CC BY 4.0); AWS Kosten mit AWS Cost Categories organisieren, Cost Categories anlegen, Spalte für Cost Categories im CUR 2.0 und Kontingente und Beschränkungen in Billing and Cost Management; Microsoft Überblick über Management Groups, Scopes in Cost Management, Einführung in die Kostenzuordnung, Ansichten speichern und teilen und Felder der Kostendetails; Google Cloud Ressourcenhierarchie, Ordner erstellen, Struktur des Standard-Exports und Cloud-Billing-Berichte.