Zuordnung über Konten, Subscriptions und Projekte

Kostenzuordnung nach Account nutzt den Container, in dem eine Ressource läuft: das AWS-Konto, die Azure-Subscription mit ihrer Ressourcengruppe oder das Google-Cloud-Projekt. Diese Kontenstruktur steht auf jeder Nutzungsposition der Abrechnungsdaten, auch für zurückliegende Monate, ohne dass an einer einzigen Ressource etwas gesetzt werden muss; ein Tag leistet beides nicht. Gehört jeder Container genau einem Verantwortlichen, ist die Kostenzuordnung damit bereits exakt. Im Whitepaper von AWS zur Multi-Account-Struktur heißt es entsprechend, das Konto sei das Standardmittel, über das AWS-Kosten zugeordnet werden. Wie Workloads auf Konten, Subscriptions und Projekte verteilt werden, ist deshalb die billigste und dauerhafteste Entscheidung über ihre Zuordnung.

So funktioniert es

Bei allen drei Providern gibt es zwei Ebenen. Der Container ist die Einheit, in der Ressourcen angelegt werden und deren Kennung jede Nutzungsposition trägt. Darüber liegt eine Hierarchie, die Container zu größeren Einheiten zusammenfasst, vor allem für Zugriffsrechte und Richtlinien, und die sich auch für Berichte nutzen lässt. Getrennt davon steht ein zweiter Baum, die Abrechnungshierarchie. Sie bestimmt, welches Abrechnungskonto zahlt, nicht wem eine Ressource gehört; Abrechnungskonten und Hierarchien beschreibt sie.

AWS

Das Whitepaper Organizing Your AWS Environment Using Multiple Accounts empfiehlt mehrere Konten statt eines einzigen, getrennt nach Workloads und Umgebungen, und hält fest, dass AWS nach Nutzung abrechnet, nicht nach der Zahl der Konten. In AWS Organizations fassen Organisationseinheiten (OUs) Konten zusammen, verschachtelt bis zu fünf Ebenen unter dem Root. Im Cost and Usage Report 2.0 trägt jede Position line_item_usage_account_id und line_item_usage_account_name, also das Konto, das sie verursacht hat, ob Management- oder Mitgliedskonto; das zahlende Management-Konto steht getrennt in bill_payer_account_id (AWS Cost and Usage Report und Data Exports). Die OU gehört nicht zu den Line-Item- und Bill-Spalten. Abbilden lässt sie sich über Account-Tags: Tags an Konten in AWS Organizations, die in der Billing-and-Cost-Management-Konsole unter Cost Allocation Tags aktiviert werden. Laut AWS gelten sie für die gesamte gemessene Nutzung eines getaggten Kontos, auch für Erstattungen, Gutschriften und bestimmte Servicegebühren, die sich nicht auf Ressourcenebene taggen lassen. In den Berichten tragen sie das Präfix accountTag, und die Aktivierung kann bis zu 24 Stunden dauern.

Azure

Azure hat zwei Container-Ebenen: die Subscription und darin die Ressourcengruppe, in der jede Ressource liegt. Darüber ordnen Management Groups die Subscriptions zu einem Baum unter der Root Management Group des Verzeichnisses. Ein Verzeichnis unterstützt bis zu 10.000 Management Groups, der Baum bis zu sechs Ebenen, Root und Subscription-Ebene nicht mitgezählt, und jede Management Group und jede Subscription hat genau einen Elternknoten. Die Kostendetails enthalten SubscriptionId, SubscriptionName und ResourceGroup; Posten ohne Ressourcengruppe zeigen dort einen leeren Wert, Others oder Not applicable. Eine Management Group nennen die Kostendetails nicht. In Cost Management ist sie ein Scope, auf dem sich die Kostenanalyse öffnen lässt, mit dokumentierten Einschränkungen: Für Subscriptions unter einem Microsoft Customer Agreement und in CSP-Scopes unterstützen die Cost-Management-Funktionen Management Groups derzeit nicht, die Cost Details API unterstützt sie weder für EA noch für MCA, und eine Management Group summiert nur nutzungsbasierte Kosten. Käufe wie Reservierungen oder Marketplace-Angebote von Drittanbietern zeigt erst die Abrechnungsebene: das EA-Abrechnungskonto oder das MCA-Abrechnungskonto mit seinen Abrechnungsprofilen (Azure Cost Management and Billing).

Google Cloud

Bei Google Cloud ist das Projekt der Container, und jede Dienstressource gehört genau einem Projekt. Darüber steht die Organisation als Wurzel, dazwischen optional Ordner; jede Ressource außer der obersten hat genau einen Elternknoten. Ordner lassen sich bis zu zehn Ebenen tief verschachteln. Im Standard-Nutzungsexport trägt jede Position eines Projekts project.id und project.name, die Labels des Projekts in project.labels und die Hierarchie darüber in project.ancestors, geordnet vom Projekt über die Ordner bis zur Organisation; das Feld ist ab April 2022 gefüllt. Laut dem Schema von Google hält project.ancestry_numbers die Vorfahren zum Zeitpunkt der Nutzung fest: Ein Projekt, das später in einen anderen Ordner wandert, bleibt in alten Zeilen am alten Ort (Google-Cloud-Abrechnungsexport nach BigQuery). Die Cloud-Billing-Berichte gruppieren mit der Option Project hierarchy nach Organisation, Ordner und Projekt für Zeiträume ab dem 2022-01-01; Kosten ohne Projekt erscheinen beim Gruppieren nach Projekt als „Charges not specific to a project“. Das Cloud-Billing-Konto gehört nicht zu diesem Baum. Google trennt Eigentum, also die IAM-Vererbung, von der Zahlungsverknüpfung, und ein Abrechnungskonto kann Projekte einer anderen Organisation bezahlen.

Die drei Provider nebeneinander

Was es für Ihre Kosten bedeutet

Ein Bericht nach Konto, Subscription oder Projekt erfasst als einzige Gruppierung ohne Vorarbeit jede Nutzungsposition. Gehört jeder Container einem Team, genügt eine Liste von Container zu Team, um die Rechnung aufzuteilen, und diese Liste gilt rückwirkend, weil die Kennung schon auf den alten Positionen steht. Die Hierarchie darüber liefert die nächste Verdichtung, etwa vom Team zur Abteilung; wie solche Verdichtungen gebaut werden, beschreibt Segmente und Hierarchien der Kostenzuordnung.

Ein Container mit genau einem Verantwortlichen wird exakt zugeordnet, einer mit mehreren nur über Tags oder Regeln. Laufen Produktion und Entwicklung in getrennten Konten, Subscriptions oder Projekten, ist auch die Umgebung ohne Tag sichtbar. Nicht erreicht werden Kosten, die beim Käufer oder Zahler entstehen: Commitment-Käufe, Support und Marketplace-Käufe stehen bei dem Konto, das gekauft hat, oder auf der Abrechnungsebene und brauchen eine Regel für geteilte Kosten, wie sie Geteilte Kosten und wie man sie verteilt beschreibt.

Wo es schiefgeht

• Geteilte Konten und Plattformprojekte. Symptom: Ein Konto oder Projekt mit Namen wie shared oder platform trägt einen großen Teil der Rechnung, und niemand ist zuständig. Ursache: Der Container beherbergt Workloads mehrerer Teams, die Dimension kann aber nur einen Verantwortlichen nennen; den Rest müssen Tags oder eine Verteilungsregel leisten.
• Käufe beim Zahler. Symptom: Die Summe der Teamkonten liegt unter der Rechnung, und bei Azure zeigt die Root Management Group eine andere Summe als das Abrechnungskonto. Ursache: Reservierungen, Savings Plans, Support und Marketplace werden dort berechnet, wo sie gekauft wurden, oder auf der Abrechnungsebene; bei Azure enthalten weder Management Groups noch EA-Abteilungen noch MCA-Rechnungsabschnitte solche Käufe.
• Management Groups unter MCA. Symptom: Eine Auswertung je Management Group fehlt für Subscriptions unter einem Microsoft Customer Agreement oder lässt sich nicht über die Cost Details API abrufen. Ursache: Microsoft unterstützt Management Groups in Cost Management für MCA derzeit nicht und in der Cost Details API für keinen der beiden Vertragstypen.
• Umzug in der Hierarchie. Symptom: Die Kostenreihe eines Ordners oder einer OU springt im Monat einer Umorganisation. Ursache: Container wurden verschoben. Google belässt alte Zeilen am alten Ort, eine Zuordnungsliste ohne Gültigkeitsdatum wendet dagegen die neue Struktur auf alle Monate an.

Quellen

Gelesen am 2026-10-16. AWS Organizing Your AWS Environment Using Multiple Accounts mit dem Abschnitt Vorteile mehrerer AWS-Konten, Kontingente von AWS Organizations, Account-Tags für die Kostenzuordnung, Kosten mit AWS Cost Categories organisieren, Line-Item-Spalten und Bill-Spalten des CUR 2.0; Microsoft Überblick über Management Groups, Scopes in Cost Management und Felder der Kostendetails; Google Cloud Ressourcenhierarchie, Ordner erstellen, Überblick über Cloud Billing, Struktur des Standard-Exports und Cloud-Billing-Berichte.