Nicht zugeordnete Kosten sind der Teil der Cloud-Rechnung, den kein Konto, kein Tag und keine Regel einem Verantwortlichen zuweist: ein Rest, der als eigene Position im Bericht stehen bleibt und eine eigene Person braucht, die ihn verkleinert. Seine Größe ist das Gegenstück zum Zuordnungsgrad. Für die Rechnung zählt das, weil Kosten in diesem Rest in jedem Teambericht, jedem Budget je Verantwortlichem und jeder Stückkostenzahl fehlen und dort niemand eine Einsparung umsetzt oder eine Anomalie erklärt. Wird der Rest unbemerkt auf alle umgelegt, sind die Berichte vollständig, aber nicht mehr richtig.
So funktioniert es
Kostenzuordnung arbeitet in Schichten. Zuerst ordnet die Kontenstruktur jede Position ihrem Konto, ihrer Subscription oder ihrem Projekt zu, dann ergänzen Tags den Verantwortlichen an der Ressource, danach greifen Zuordnungsregeln, und zuletzt verteilt ein Schlüssel die geteilten Kosten. Was durch alle Schichten fällt, ist der nicht zugeordnete Rest. Die FinOps Foundation verfolgt diesen Rest in ihrer Capability Allocation (Domäne Understand Usage & Cost) mit eigenen KPIs: seine Größe, gerechnet als effektive Kosten der nicht zugeordneten Ressourcen geteilt durch die gesamten Cloud-Kosten des Zeitraums, und wie lange es im Mittel dauert, bis solche Kosten erklärt und einem Verantwortlichen zugewiesen sind.
Woraus der Rest besteht
| Bestandteil | Beispiel | Warum nichts greift | Weg aus dem Rest |
|---|---|---|---|
| Nicht getaggte Nutzung | eine Datenbank ohne den Schlüssel für das Team | der Tag fehlt an der Ressource | Tag setzen, für Vergangenes eine Regel |
| Nicht taggbare Posten | Support, Steuern, Gebühren | sie hängen an keiner Ressource | Regel oder Verteilung als geteilte Kosten |
| Commitments | ungenutzter Teil einer Reservierung oder eines Savings Plan | er gehört dem Käufer, keiner Workload | zentrales Budget oder Verteilschlüssel |
| Späte Posten | Gutschriften, Erstattungen, Nachberechnungen | sie kommen nach dem Bericht oder ohne Ressource | nach der Finalisierung erneut zuordnen |
| Clusterreste | Leerlauf und nicht zuordenbare Kapazität in Kubernetes | bezahlt werden Nodes, nicht Pods | Regel für den Cluster |
Die Anbieter benennen diese Gruppen unterschiedlich. Azure trennt in der Kostenanalyse beim Gruppieren nach einem Tag drei Fälle: Käufe, klassische und andere nicht taggbare Ressourcen erscheinen als Tags not supported, Dienste, deren Nutzungsdaten keine Tags tragen, als Tags not available, und nur der Rest als Untagged. Bei Google Cloud gehören Supportkosten dem Cloud-Billing-Konto und keinem Projekt; im Export bleiben bei diesen Posten und den Steuern darauf die Projektspalten leer. Bei AWS lassen sich solche Posten über die Dimension Charge type einer Regel zuführen, etwa Tax, Fee, Recurring reservation fee oder Savings Plan Recurring Fee. Den ungenutzten Teil von Reservierungen und Savings Plans zeigt Azure nur in der amortisierten Sicht, als eigene Position.
In Kubernetes hat jedes Werkzeug eigene Töpfe. Das Add-on für die Kostenanalyse von AKS weist Unallocated charges aus (Kosten, die keinem Namespace zugeordnet werden konnten) und getrennt davon Idle charges für ungenutzte Kapazität. GKE schreibt Kapazität, die weder ein Workload noch das System angefordert hat, in den Namespace kube:unallocated. Die OpenCost-API führt Leerlauf mit includeIdle als eigene Zuordnung __idle__. Dasselbe Wort meint also nicht dasselbe: Was GKE unallocated nennt, liegt bei AKS unter idle. Wie diese Reste im Cluster entstehen, beschreibt Kubernetes-Kostenzuordnung.
Wo er in den Daten erscheint
| Anbieter | Native Sicht auf den Rest | Wo er in den Daten steht |
|---|---|---|
| AWS | Kostenkategorie: Zeilen ohne passende Regel erhalten den Standardwert, ohne Standardwert zeigt die Detailseite sie als Uncategorized | Spalte der Kostenkategorie im CUR, Dimension in Cost Explorer und AWS Budgets |
| Azure | Gruppen Untagged, Tags not available und Tags not supported in der Kostenanalyse | Posten ohne den Tag in den Kostendetails |
| Google Cloud | im BigQuery-Export tragen Zeilen ohne den Label-Schlüssel einen leeren Wert | Zeilen ohne den Label-Schlüssel und Zeilen mit leeren Projektspalten im BigQuery-Export |
AWS wendet eine neue oder geänderte Kostenkategorie ab dem ersten Tag des laufenden Monats an und braucht bis zu 24 Stunden, bis sie angewendet ist. Ein Standardwert mit einem eindeutigen Namen macht den Rest in allen AWS-Werkzeugen zu einer sichtbaren Zeile.
Was es für Ihre Kosten bedeutet
Im Kostenbericht steht der Rest als eigene Zeile neben den Teams, und Teams plus Rest ergeben die Rechnung. Sein Anteil an den Gesamtkosten, Monat für Monat, ist die Begleitzahl zum Zuordnungsgrad: Steigt er, ist eine Kostenquelle ohne Verantwortlichen hinzugekommen; sinkt er, hat jemand Tags gesetzt oder eine Regel geschrieben. Aufgeschlüsselt nach Bestandteilen zeigt der Bericht auch, wer handeln kann. Nicht getaggte Nutzung schließen die Teams, die Ressourcen anlegen (Tag-Abdeckung und nicht getaggte Kosten). Nicht taggbare Posten brauchen eine Regel, Commitments eine Entscheidung über ihren Käufer. Späte Posten klären sich erst mit Nachberechnung und Finalisierung des Monats (Aktualität, Nachberechnung und Finalisierung).
Den Rest standardmäßig zu verteilen, etwa im Verhältnis zu den direkten Kosten der Teams, lässt die Teamsummen aufgehen. Jedes Team trägt dann aber Kosten, die es weder sieht noch beeinflussen kann, und niemand hat mehr einen Anlass, die Lücke zu schließen. Die FinOps Foundation beschreibt in der Capability Allocation, dass viele Praktiken am Anfang geteilte Kosten per „informed ignore“ behandeln: Sie lassen diese Posten bewusst in einem zentralen Budget und belasten damit keine Kostenstelle. Für den Rest gilt dieselbe Logik. Ist eine Verteilung vereinbart, ist sie eine Regel für geteilte Kosten mit eigenem, datiertem Schlüssel, und der Bericht zeigt den Rest vor der Verteilung weiterhin an.
Der Rest braucht einen benannten Verantwortlichen, der ihn im monatlichen Review vorlegt (Monatliches Cloud-Kostenreview), einzelne Posten an Teams weitergibt und den Verlauf verfolgt. Welche Rolle das ist, legt das Betriebsmodell fest (FinOps-Rollen und Verantwortlichkeiten). Pflichtangaben schon bei der Bereitstellung durchzusetzen, gehört zur Governance und verhindert neue Lücken, klärt aber nicht den bestehenden Rest.
Wo es schiefgeht
- Der Rest wird stillschweigend umgelegt. Symptom: Die Teamsummen ergeben genau die Rechnung, und trotzdem steigen die Kosten aller Teams ohne erkennbare Ursache. Ursache: Eine Umlage verteilt den Rest, und dass er wächst, sieht niemand mehr.
- Ein Topf für alles. Symptom: Die Zeile „nicht zugeordnet“ wird Monat für Monat größer, und keiner fühlt sich zuständig. Ursache: Nicht getaggte Nutzung, nicht taggbare Posten, Commitments und späte Posten stehen zusammen, obwohl jeder Bestandteil einen anderen Weg hinaus hat.
- Der Standardwert zeigt auf ein Team. Symptom: In einer AWS-Kostenkategorie gibt es keinen Rest, aber ein Team wächst ohne eigene Änderungen. Ursache: Der Standardwert der Kategorie ist ein echtes Team statt eines eindeutig benannten Rests.
- Clusterreste fehlen im Bericht. Symptom: Die Namespaces ergeben weniger als die Clusterkosten auf der Rechnung. Ursache: Idle und Unallocated charges von AKS oder
kube:unallocatedvon GKE werden nicht als eigene Zeilen geführt. - Der Rest ändert sich nach Monatsende. Symptom: Ein abgeschlossener Monat zeigt beim nächsten Abruf einen anderen Rest. Ursache: Gutschriften, Erstattungen und Nachberechnungen treffen spät ein, oft ohne die ursprüngliche Ressource.
Quellen
Gelesen am 2026-10-16. FinOps Foundation Capability Allocation (CC BY 4.0); AWS Kosten mit AWS Cost Categories ordnen und Kostenkategorien anzeigen; Microsoft Gruppier- und Filteroptionen in Cost Analysis und Budgets und Kostenanalyse für Azure Kubernetes Service (AKS); Google GKE-Kostenzuordnung und Struktur des Standard-Datenexports; OpenCost OpenCost Specification und API.