Geteilte Kosten in der Cloud sind Kosten, die mehreren Verantwortlichen zugleich dienen und deshalb keinem einzelnen Konto, Tag oder Team allein gehören: ein zentrales Netzwerk, Sicherheits- und Monitoring-Plattformen, der Support-Plan, ein gemeinsam genutzter Cluster oder eine gemeinsame Datenbank. Für die Kostenzuordnung sind sie keine Tagging-Lücke, denn ein Tag nennt genau einen Verantwortlichen. Sie brauchen eine Regel, die sie nach einem Schlüssel aufteilt. Bleiben sie zentral, sehen die Teams nur ihre direkten Kosten, und Stückkosten und Budgets fallen niedriger aus als der Betrieb, der sie trägt. Werden sie verteilt, entscheidet der Schlüssel, wer wie viel trägt.
So funktioniert es
Geteilt ist, was mehrere nutzen und eine Stelle bezahlt: zentrale Netzwerke und Gateways, Sicherheits- und Monitoring-Dienste, Support-Pläne, Commitments, deren Rabatt über mehrere Konten oder Subscriptions wirkt, sowie geteilte Cluster und Datenbanken. AWS nennt Datentransfer, Enterprise Support und Betriebskosten, die mehrere Teams gemeinsam verursachen; Microsoft beschreibt zentrale Subscriptions mit gemeinsamer Infrastruktur, deren Kosten an die nutzenden Teams gehen. Für Kubernetes-Cluster gilt dieselbe Logik eine Ebene tiefer, mit eigenen Fragen zu Leerlauf und Systemlast (Kubernetes-Kostenzuordnung nach Namespace und Label).
Die Schlüssel
Die FinOps Foundation führt in ihrer Capability Allocation eine eigene Strategie für geteilte Kosten neben der Zuordnungs- und der Tagging-Strategie. Danach wird je geteiltem Posten entschieden, ob er verteilt oder bewusst zentral budgetiert wird; den zweiten Weg nennt die Foundation „informed ignore“. Verteilt wird fest, proportional oder über Hilfsgrößen, die den Verbrauch annähern.
| Schlüssel | Berechnung | Was er annimmt |
|---|---|---|
| Proportional zu den direkten Kosten | Anteil des Ziels an den direkten Kosten aller Ziele | Die geteilte Leistung wächst mit dem direkten Verbrauch. |
| Proportional zu einem Nutzungstreiber | Anteil an Anfragen, Gigabyte oder CPU-Stunden | Der Treiber misst die Nutzung der geteilten Leistung. |
| Gleich | Betrag geteilt durch die Zahl der Ziele | Alle profitieren gleich. |
| Fest | vereinbarte Prozentsätze | Die Nutzung verschiebt sich selten. |
Welcher Schlüssel angemessen ist, entscheidet die Organisation; die Rechnung des Providers ändert keiner. Für jeden gilt: Die verteilten Anteile ergeben zusammen genau den geteilten Betrag, und die Regel ist für jeden sichtbar, der eine verteilte Zahl liest.
| Provider | Mechanismus | Schlüssel | Ergebnis sichtbar in |
|---|---|---|---|
| AWS | Split Charge Rules in Cost Categories | Proportional, Fixed, Even split | nur auf der Detailseite der Cost Category und als CSV |
| Azure | Kostenzuordnungsregeln | gleichmäßig, nach Gesamt-, Compute-, Storage- oder Netzwerkkosten, feste Prozente | Kostenanalyse, Budgets, Prognosen, Exporte |
| Google Cloud | eingebaut nur für Committed Use Discounts und GKE-Cluster, sonst Abfrage über den BigQuery-Export | proportional oder priorisiert (Commitments), nach Ressourcenanforderungen (GKE), sonst frei wählbar | Export und Konsole (Commitments), detaillierter Export (GKE), sonst eigene Tabellen |
AWS
Split Charge Rules sind Teil der Cost Categories. Die Quelle ist ein Wert, der die geteilten Kosten sammelt, die Ziele sind andere Werte derselben Kategorie; proportional heißt hier im Verhältnis der gewichteten Kosten der Ziele. Ein Wert kann nur in einer einzigen Regel Quelle sein und dann nicht zugleich Ziel; je Cost Category sind zehn Split Charge Rules erlaubt. Weil die Regeln von oben nach unten greifen, empfiehlt AWS, die Werte mit geteilten Kosten an den Anfang der Regelliste zu stellen. Beim Bearbeiten lässt sich auch der nicht kategorisierte Rest (Uncategorized cost) als Quelle wählen. Die Grenze liegt in der Sichtbarkeit: Cost Explorer, der Cost and Usage Report und die übrigen Werkzeuge zeigen die Werte unverteilt.
Azure
Kostenzuordnungsregeln verschieben Kosten von Subscriptions, Ressourcengruppen oder Tags auf Subscriptions, Ressourcengruppen oder Tags als Ziele. Die Compute-, Storage- und Netzwerkkosten sind die Kosten der Ressourcentypen in den Namespaces Microsoft.Compute, Microsoft.Storage und Microsoft.Network im laufenden Abrechnungsmonat; feste Prozente sind ganze Zahlen mit der Summe 100. Einmal gesetzt, bleiben die vorbelegten Prozentsätze fest, bis jemand die Regel ändert, ein proportionaler Schlüssel ist bei Azure also eine Momentaufnahme. Ein Ziel ohne eigene Kosten erhält nichts. Käufe wie Reservierungen und Savings Plans lassen sich nicht verteilen, die Rechnung bleibt unverändert, und verfügbar ist die Funktion für Enterprise Agreement und Microsoft Customer Agreement. Im Export erscheint jede Verteilung als Zeilenpaar mit costAllocationRuleName; die Usage Details API und die Power-BI-Anbindungen zeigen sie nicht. Wie Regeln allgemein arbeiten, beschreibt Virtuelle Tags und Zuordnungsregeln.
Google Cloud
Google Cloud verteilt zwei Arten geteilter Kosten selbst: Gebühren und Gutschriften von Committed Use Discounts auf die Projekte, proportional zur berechtigten Nutzung oder nach einer festgelegten Zuteilung, und mit der GKE-Kostenzuordnung die Kosten eines Clusters nach Namespace und Label, berechnet aus den Ressourcenanforderungen. Für alle übrigen geteilten Kosten nennt Google eine zentrale IT-Kostenstelle oder eine proportionale Aufteilung nach der Zahl der Workloads, gerechnet über den BigQuery-Export.
Was es für Ihre Kosten bedeutet
Eine Verteilung ändert die Kosten jedes Ziels und damit seine Stückkosten und den Abgleich mit seinem Budget. Deshalb wird der Schlüssel vereinbart und mit Datum festgehalten, und eine Änderung wirkt ab einem genannten Monat; bei AWS gilt eine geänderte Cost Category ab dem Ersten des laufenden Monats oder rückwirkend ab einem gewählten Startdatum. Ein Bericht je Verantwortlichem zeigt direkte und verteilte Kosten getrennt, damit sichtbar bleibt, was ein Team selbst steuern kann. Was nach allen Regeln übrig bleibt, steht als eigener Posten im Bericht und wird nicht still auf alle umgelegt; das behandelt Nicht zugeordnete Kosten.
Weil AWS die Aufteilung nicht in den Cost and Usage Report schreibt, muss eine Weiterbelastung auf Basis der Exportdaten sie außerhalb nachrechnen. Bei Azure stehen die verteilten Beträge im Export und werden für den Abgleich mit der Rechnung herausgefiltert. Wird zwischen Gesellschaften weiterbelastet, entscheiden Steuerberater oder Wirtschaftsprüfer über die Behandlung.
Wo es schiefgeht
- Quelle zugleich Ziel. Symptom: Die Kosten der Plattform lassen sich bei AWS nicht auf die Teams und zugleich weiter verteilen. Ursache: Ein Wert, der Quelle einer Split Charge Rule ist, kann nicht Ziel sein, und jeder Wert ist nur einmal Quelle.
- Aufteilung im Export erwartet. Symptom: Cost Explorer und Cost and Usage Report zeigen andere Teamkosten als die Detailseite der Cost Category. Ursache: Split Charges erscheinen nur auf der Detailseite.
- Veraltete Azure-Prozente. Symptom: Die Anteile passen Monate später nicht mehr zur Nutzung. Ursache: Die vorbelegten Prozentsätze bleiben fest, bis die Regel geändert wird.
- Reservierung bleibt zentral. Symptom: Ein Reservierungskauf steht weiter in der zentralen Subscription. Ursache: Azure-Kostenzuordnungsregeln unterstützen keine Käufe.
- Schlüssel ohne Datum geändert. Symptom: Budgets und Stückkosten springen, ohne dass sich die Nutzung ändert. Ursache: Der Schlüssel wurde ohne festgehaltenes Datum geändert, und bei AWS wirkt die Änderung ab dem Ersten des laufenden Monats.
Quellen
Gelesen am 2026-10-16. FinOps Foundation Allocation (CC BY 4.0); AWS Kosten innerhalb von Cost Categories aufteilen, Cost Categories anlegen, Cost Categories bearbeiten und Kontingente und Einschränkungen; Microsoft Azure-Kostenzuordnungsregeln anlegen und verwalten und Einführung in die Kostenzuordnung; Google Cloud Zuordnung von CUD-Gebühren und -Gutschriften, GKE-Kostenzuordnung und Kosten und Zuordnung verwalten.