Virtuelle Tags und Zuordnungsregeln

Virtuelle Tags sind Zuordnungsmerkmale, die aus den Abrechnungsdaten berechnet werden, statt an der Ressource zu stehen: Eine Zuordnungsregel liest Konto, Dienst, Ressourcenname oder vorhandene Tags und schreibt in jeden Posten einen Wert wie Team oder Produkt. Keiner der drei Anbieter verwendet den Begriff; AWS nennt die Funktion Cost Categories, Microsoft Kostenzuordnungsregeln. Mit solchen Regeln erreicht die Zuordnung, was Tagging nicht erreicht: Posten ohne Ressource, Schlüssel in mehreren Schreibweisen und Monate, in denen noch niemand getaggt hatte. Der Zuordnungsgrad steigt, ohne dass eine Ressource angefasst wird. Dafür wird die Zuordnung zu Logik, die jemand pflegen, prüfen und datieren muss.

So funktioniert es

Eine Regelliste wird von oben nach unten gelesen. Der erste Treffer bestimmt den Wert, ein Standardwert fängt auf, was keine Regel trifft. Bedingungen sind Felder, die jeder Posten trägt, vom Konto über den Dienst bis zu vorhandenen Tags. Ein virtueller Tag für die Kostenstelle liest etwa zuerst den Schlüssel cost-center, dann die Varianten CostCenter und costcentre und fällt zuletzt auf das Konto zurück. Weil die Regel auf den Abrechnungsdaten läuft, gilt sie für jeden Monat, den die Daten enthalten, soweit das Werkzeug sie rückwirkend anwendet; ein Tag an der Ressource gilt erst ab dem Datum, an dem er gesetzt wurde. Das Ergebnis ist eine Dimension, nach der Berichte gruppieren, ein Segment; wie daraus Hierarchien werden, beschreibt Segmente und Hierarchien der Kostenzuordnung.

AWS

AWS Cost Categories ist die eingebaute Regel-Engine. Eine Cost Category ist ein Schlüssel, ihr Wert steht an jedem Posten, den eine Regel trifft. Die Operatoren sind Is, Is not, Is absent, Contains, Starts with und Ends with; die drei letzten gibt es nur für Konten und Tags, und sie unterscheiden Groß- und Kleinschreibung. Regular Rules setzen einen festen Wert, Inherited-Value-Rules übernehmen den Wert eines Tag-Schlüssels oder den Kontonamen. Die erste passende Regel gewinnt, ein optionaler Standardwert nimmt den Rest auf. Anlegen kann sie das Management-Konto einer Organisation oder ein Einzelkonto; erlaubt sind 50 Cost Categories mit je 500 Regeln über die API und 100 in der Konsole.

Eine neue oder geänderte Cost Category gilt ab dem Ersten des laufenden Monats, mit einem früheren Startdatum rückwirkend, höchstens zwölf Monate zurück. Bis die Werte überall stehen, vergehen bis zu 24 Stunden; der Status wechselt dann von Processing zu Applied. In CUR 2.0 erscheint ein Schlüssel der Map-Spalte cost_category nur, wenn er für den Posten einen Wert hat.

Azure

Azure hat zwei Mechanismen. Die Tag-Vererbung ist eine fest eingebaute Regel: Sie schreibt die Tags von Subscription und Ressourcengruppe, bei Microsoft Customer Agreement auch von Abrechnungsprofil und Rechnungsabschnitt, in die Nutzungsdatensätze darunter, ab dem laufenden Monat; bei gleichem Schlüssel gewinnt standardmäßig der Tag der Ressource. Kostenzuordnungsregeln (cost allocation rules) verschieben Kosten von Quellen, also Subscriptions, Ressourcengruppen oder Tags, auf Subscriptions, Ressourcengruppen oder Tags als Ziele: gleichmäßig, mit festen ganzzahligen Prozenten oder im Verhältnis der Gesamt-, Compute-, Storage- oder Netzwerkkosten der Ziele. Sie laufen in der Reihenfolge ihrer Anlage und brauchen bis zu 24 Stunden. Verfügbar sind sie für Enterprise Agreement und Microsoft Customer Agreement, im Enterprise-Vertrieb wie online abgeschlossen. Käufe wie Reservierungen und Savings Plans verschieben sie nicht, die Rechnung ändern sie nicht. Wie Azure damit geteilte Kosten verteilt, beschreibt Geteilte Kosten und wie man sie verteilt.

Google Cloud

Cloud Billing hat keine Regel-Engine wie Cost Categories: Die Berichte gruppieren nur nach festen Dimensionen wie Projekt, Projekthierarchie, Service und SKU sowie nach Label-Schlüsseln. Die Bausteine liegen im BigQuery-Export: project.labels an jedem Posten, project.ancestors mit Ordnern und Organisation, labels, tags mit dem Vermerk inherited, Service und SKU. Eine Regel ist dort eine SQL-Abfrage, etwa ein CASE-Ausdruck in einer View: die Bedingungen in fester Reihenfolge, der ELSE-Zweig als Standardwert. Google veröffentlicht Beispielabfragen für Labels, Tags und die Ressourcenhierarchie, aus denen sich solche Regeln zusammensetzen.

FOCUS

Die FinOps Open Cost and Usage Specification (FOCUS) hat seit Version 1.3 Spalten für Aufteilungen: AllocatedMethodId, AllocatedMethodDetails, AllocatedResourceId, AllocatedResourceName und AllocatedTags. Sie beschreiben Aufteilungen, die der Datenlieferant selbst berechnet hat, etwa die Kosten eines Knotens in einem geteilten Cluster, verteilt auf die Workloads. Die Teilposten ergeben zusammen den Ursprungsposten, und der nicht zugeordnete Teil hat keine AllocatedResourceId. Eigene Regeln eines Unternehmens füllen diese Spalten nicht; wer ihr Ergebnis in einem FOCUS-Datensatz führt, braucht eine zusätzliche Spalte, für die FOCUS das Präfix x_ vorschreibt. Die Spalten im Einzelnen beschreibt FOCUS-Spalten und das Mapping der Anbieter.

Was es für Ihre Kosten bedeutet

Ein Wert aus einer Regel ist kein Tag. Ein Bericht, der beides mischt, zeigt hohe Abdeckung, während die Ressourcen ungetaggt bleiben. Deshalb führt ein sauberer Bericht mit, ob ein Wert vom Tag, vom Konto oder aus welcher Regel stammt, und misst die Tag-Abdeckung getrennt. Der Standardwert ist dabei die aufschlussreichste Zeile: Was dort landet, hat keine Regel getroffen.

Regeln ändern die Vergangenheit. Bei AWS wirkt jede Änderung mindestens ab dem Ersten des laufenden Monats, mit früherem Startdatum bis zu zwölf Monate zurück. Bei Azure ist eine geänderte Regel nach bis zu zwei Stunden neu verarbeitet; wie weit sie zurückwirkt, dokumentiert Microsoft nicht. Regeln brauchen deshalb ein Änderungsprotokoll mit Datum und Grund, zum Beispiel als Code in einem versionierten Repository.

Die Summe bleibt erhalten. Bei AWS hat jeder Posten je Cost Category höchstens einen Wert, und ohne Standardwert bleiben nicht getroffene Posten ohne Wert. Azure-Kostenzuordnungsregeln erzeugen im Export ein Paar aus einer negativen Zeile bei der Quelle und einer positiven beim Ziel; für den Abgleich mit der Rechnung rät Microsoft, diese Zeilen herauszufiltern.

Wo es schiefgeht

• Überlappende Regeln. Symptom: Nach einer neuen Regel sinken die Kosten eines Teams, ohne dass sich die Nutzung ändert. Ursache: Bei AWS gewinnt die erste passende Regel; bei Azure greift eine später angelegte Regel ins Leere, wenn eine frühere die Quelle schon ganz verteilt hat.
• Regel verdeckt die Tagging-Lücke. Symptom: Die Zuordnung liegt nahe hundert Prozent, aber Teams finden ihre Ressourcen nicht. Ursache: Ein breiter Standardwert oder eine Kontoregel ordnet alles zu, und niemand misst die Tag-Abdeckung getrennt.
• Regeländerung ohne Datum. Symptom: Die Zahlen des letzten Quartals haben sich geändert, und niemand weiß warum. Ursache: Die Änderung wirkte rückwirkend und ist nirgends festgehalten.
• Schreibweise in der Bedingung. Symptom: Eine Contains-Regel trifft einen Teil der Posten nicht. Ursache: Contains, Starts with und Ends with unterscheiden bei AWS Groß- und Kleinschreibung.
• Kauf in der Azure-Regel erwartet. Symptom: Eine Reservierung bleibt in der zentralen Subscription. Ursache: Kostenzuordnungsregeln verschieben keine Käufe.

Quellen

Gelesen am 2026-10-16. AWS Kosten mit AWS Cost Categories ordnen, Cost Categories anlegen, Kontingente und Einschränkungen, CreateCostCategoryDefinition und Cost-Category-Spalten in CUR 2.0; Microsoft Azure-Kostenzuordnungsregeln anlegen und verwalten und Kosten mit Tag-Vererbung gruppieren; Google Cloud Beispielabfragen für den Abrechnungsexport, Struktur des Standard-Datenexports und Abrechnungsdaten und Kostentrends mit Berichten analysieren; FinOps Foundation FOCUS-Spaltenbibliothek, Vom Datenlieferanten berechnete Kostenaufteilung, Behandlung der vom Datenlieferanten berechneten Kostenaufteilung, Allocated Resource ID und Behandlung eigener Spalten.