Kostenzuordnung ist die Zuweisung jeder Position der Cloud-Rechnung an einen Verantwortlichen: über die Konten, Subscriptions und Projekte, in denen die Ressourcen laufen, über Tags an den Ressourcen und über Regeln auf den Abrechnungsdaten. Sie beantwortet die Frage, wer über eine Position entscheidet. Ob die Position zu hoch ist, beantwortet sie nicht; das ist die Frage der Optimierung, und die lässt sich erst sinnvoll stellen, wenn feststeht, an wen sie geht. Für die Rechnung ist diese Reihenfolge entscheidend. Eine Einsparungschance, ein Budget oder eine Anomalie bewegt nur dann etwas, wenn sie jemanden erreicht, der die Ressource ändern darf. Ohne diesen Empfänger bleibt eine Empfehlung eine Zeile in einer Liste, und die Kosten bleiben auf der Rechnung.
So funktioniert es
Das FinOps Framework der FinOps Foundation führt Allocation als eigene Capability in der Domain Understand Usage & Cost; wo sie unter den übrigen Capabilities steht, zeigt Die vier Domains und ihre Capabilities. Die Foundation sieht in Allocation die Voraussetzung für ihr Prinzip „Everyone takes ownership for their technology usage“: Verantwortung für die eigene Nutzung übernimmt nur, wer erkennen kann, welche Kosten die eigenen sind. Neben der direkten Zuordnung behandelt die Capability ausdrücklich auch die Verteilung dessen, was mehreren gehört.
Die drei großen Anbieter kommen in ihrer eigenen Dokumentation zum selben Schluss. AWS verbindet im Cost Optimization Pillar des Well-Architected Framework, im Abschnitt Expenditure and usage awareness, einen sparsameren Umgang mit Ressourcen und weniger Verschwendung damit, dass sich Kosten einem Workload, einer Organisationseinheit oder einem Produktverantwortlichen zurechnen lassen. Google Cloud empfiehlt im eigenen Well-Architected Framework unter dem Prinzip Foster a culture of cost awareness ein System, das jedem Team oder Projekt einen Teil des Cloud-Budgets zuweist, und ein einheitliches Set von Labels, mit dem sich Kosten Projekten, Abteilungen oder Kostenstellen zuordnen lassen. Microsoft beginnt seine Einführung in die Kostenzuordnung in Cost Management mit der Definition der FinOps Foundation und nennt vier Werkzeuge: die Ressourcenhierarchie aus Management Groups, Subscriptions und Ressourcengruppen, die Abrechnungshierarchie, Tags und Kostenzuordnungsregeln.
Vier Mechanismen, vom günstigsten an
Die Mechanismen bauen aufeinander auf, und jeder arbeitet mit dem, was der vorige übrig lässt. Ihre Reihenfolge folgt dem Aufwand. Die Struktur verlangt eine einmalige Entscheidung und erfasst danach jede Nutzungsposition. Ein Tag verlangt Disziplin an jeder einzelnen Ressource. Eine Regel verlangt Pflege, sobald sich Konten, Dienste oder Teams ändern. Eine Verteilung verlangt eine Einigung zwischen allen, die sie betrifft.
| Mechanismus | Was er erreicht | Was er verfehlt | Seite |
|---|---|---|---|
| Konto, Subscription, Projekt | jede Nutzungsposition des Containers, ohne Pflege an der Ressource und auch für zurückliegende Monate | mehrere Teams in einem Container, Plattformkonten, Käufe und Support auf der Ebene des Zahlers | Zuordnung über Konten, Subscriptions und Projekte |
| Tags und Labels | einzelne Ressourcen innerhalb eines Containers | Posten ohne Ressource, Zeiträume vor dem Setzen, abweichende Schreibweisen | Tags und Labels |
| Regeln und virtuelle Tags | Posten nach Bedingungen wie Konto, Dienst, Ressourcenname oder vorhandenem Tag | Posten, die in den Daten kein unterscheidendes Merkmal tragen | Virtuelle Tags und Zuordnungsregeln |
| Verteilung geteilter Kosten | Netzwerk, Sicherheit, Support und Plattformen, die mehreren dienen | die tatsächliche Verursachung, denn ein Schlüssel ist eine Vereinbarung, keine Messung | Geteilte Kosten und wie man sie verteilt |
Wer mit der dritten oder vierten Stufe beginnt, baut Regeln und Schlüssel für Kosten, die eine Kontenstruktur ohne Aufwand getrennt hätte, und muss sie pflegen, solange die Struktur bleibt, wie sie ist.
Was es für Ihre Kosten bedeutet
In den Abrechnungsdaten ist eine Zuordnung eine zusätzliche Dimension je Posten: das Konto, ein Tag-Wert oder der Wert, den eine Regel gesetzt hat. Ein Kostenbericht, der nach dieser Dimension gruppiert, ergibt in der Summe wieder die Rechnung, und was keinen Wert trägt, steht als eigene Gruppe daneben. Der Anteil mit Wert, in Geld gemessen, ist der Zuordnungsgrad. Er zeigt, wie viel der Rechnung überhaupt jemandem gehört, und damit auch, wie weit jede spätere Auswertung reichen kann.
Auf der Zuordnung bauen drei Dinge auf:
- Showback und Chargeback. Der Bericht je Verantwortlichem zeigt jedem Team seine Kosten; die Belastung der Kostenstelle macht sie zum Posten in deren Budget.
- Budgets je Verantwortlichem. Ein Schwellenwert hat nur dann einen Adressaten, wenn die Kosten darunter einem Team gehören.
- Stückkosten. Kosten je Kunde oder je Anfrage setzen voraus, dass der Zähler genau die Kosten des Produkts enthält, um das es geht.
Für die Optimierung ergibt sich daraus eine Reihenfolge, keine Rangfolge. Über die Zuordnung erreicht eine Empfehlung zum Rightsizing oder zu einer ungenutzten Ressource das Team, das die Ressource ändern kann; eine Anomalie hat einen Ansprechpartner, eine Budgetabweichung eine Erklärung. Umgekehrt ersetzt die Zuordnung keine Optimierung: Sie zeigt, wem eine Position gehört, nicht ob sie nötig ist. Wer im Unternehmen welche dieser Aufgaben übernimmt, beschreibt FinOps-Rollen und Verantwortlichkeiten; wie kleine Teams die Capabilities gewichten, ordnet FinOps Framework 2026: was kleine Teams wirklich ändern sollten ein.
Wo es schiefgeht
- Optimierung vor Zuordnung. Symptom: Die Liste der Einsparungschancen wird jeden Monat länger, umgesetzt wird wenig. Ursache: Die Empfehlungen landen bei einer zentralen Stelle, die die Ressourcen nicht ändern darf, und die Teams, die es dürften, sehen sie nicht.
- Zuordnung mit Tagging gleichgesetzt. Symptom: Nach Monaten der Tagging-Arbeit bleibt ein fester Block ohne Verantwortlichen. Ursache: Commitment-Käufe, Support und andere Posten ohne Ressource tragen keinen Ressourcen-Tag; Kontenstruktur (bei AWS auch Account-Tags), Regeln und Verteilung erreichen sie, Ressourcen-Tags nicht.
- Rest als Gemeinkosten verteilt. Symptom: Jedes Team trägt einen Aufschlag, den niemand erklären kann, und der Bericht zeigt keinen offenen Rest mehr. Ursache: Der nicht zugeordnete Rest wurde verteilt, bevor er als eigene Position sichtbar war, und damit hat niemand mehr einen Grund, ihn zu verkleinern.
- Verantwortlicher ohne Entscheidungsrecht. Symptom: Der Bericht nennt eine Kostenstelle, aber dort kann niemand die Ressourcen ändern. Ursache: Zugeordnet wurde nur nach der Stelle, die zahlt, nicht nach dem Team, das die Nutzung steuert; beides gehört in die Daten, wie Kostenstellen und Verantwortung im Team beschreibt.
Quellen
Gelesen am 2026-10-16. FinOps Foundation Capability Allocation und FinOps-Prinzipien (CC BY 4.0); AWS Expenditure and usage awareness im Cost Optimization Pillar des Well-Architected Framework und Account-Tags für die Kostenzuordnung; Microsoft Einführung in die Kostenzuordnung; Google Cloud Foster a culture of cost awareness im Well-Architected Framework.