Tags und Labels

Ein Tag ist ein Schlüssel-Wert-Paar, das Sie an eine Cloud-Ressource heften und das der Provider mit jeder Nutzungsposition dieser Ressource in die Abrechnungsdaten schreibt; bei Google Cloud heißt dasselbe Label. Ohne diese Markierung kennt die Rechnung nur Konto, Service und Region. Erst der Tag sagt, welches Team, welches Produkt und welche Kostenstelle eine Position verantwortet, und erst damit lässt sich eine Rechnung in Berichte je Verantwortlichen zerlegen. Welcher Anteil der Kosten einen solchen Verantwortlichen hat, ist die Tag-Abdeckung, die Kennzahl, an der jede Tagging-Praxis gemessen wird, und ein Teil des Zuordnungsgrads, der auch zählt, was Konten und Regeln zuordnen.

So funktioniert es

Drei Dinge sind bei allen Providern gleich. Ein Tag wird an der Ressource gesetzt, nicht in der Abrechnung. Er gilt ab dem Zeitpunkt, an dem er gesetzt wurde, nie rückwirkend. Und er erreicht die Kostendaten mit Verzögerung.

AWS

Bei AWS besteht ein Tag aus Schlüssel und Wert, und jeder Schlüssel darf je Ressource nur einmal vorkommen. Für die Abrechnung reicht das Setzen nicht: Ein Schlüssel muss in der Billing-and-Cost-Management-Konsole als Cost Allocation Tag aktiviert werden, bevor er in Cost Explorer, im Cost and Usage Report oder im Cost-Allocation-Bericht erscheint. Das kann nur das Management-Konto der Organisation, und AWS dokumentiert bis zu 24 Stunden, bis Tags in der Konsole auftauchen. Aktivierte selbst definierte Schlüssel stehen in den Berichten mit dem Präfix user:, von AWS erzeugte Tags mit aws:. Das wichtigste davon, aws:createdBy, hält fest, welcher Principal eine Ressource angelegt hat, wird aber nur für Ressourcen gesetzt, die nach der Aktivierung entstehen, nur für die dokumentierten Services und Regionen und nach bestem Bemühen aus CloudTrail-Ereignissen. Die Grenzen: höchstens 50 selbst erstellte Tags je Ressource, Schlüssel 1 bis 128 Zeichen, Werte 0 bis 256 Zeichen, beides unterscheidet Groß- und Kleinschreibung, und höchstens 500 aktive Cost-Allocation-Schlüssel je Payer-Konto.

Azure

Azure setzt Tags auf Ressourcen, Ressourcengruppen und Subscriptions, nicht auf Management Groups. Jede dieser Ebenen trägt bis zu 50 Name-Wert-Paare; Namen dürfen 512 Zeichen lang sein (128 bei Storage-Konten), Werte 256. Tag-Namen behandelt Azure bei Operationen unabhängig von der Schreibweise, der Resource Provider kann die gelieferte Schreibweise aber behalten, und genau diese erscheint dann in den Kostenberichten; Werte unterscheiden Groß- und Kleinschreibung. Ressourcen erben die Tags ihrer Ressourcengruppe oder Subscription nicht. Erben können nur die Nutzungsdatensätze: Die Einstellung Tag Inheritance in Cost Management schreibt die Tags von Subscription und Ressourcengruppe, bei Microsoft Customer Agreement auch von Abrechnungsprofil und Rechnungsabschnitt, in die Nutzungsdatensätze der untergeordneten Ressourcen, ohne die Ressourcen selbst zu ändern. Sie steht für Enterprise Agreement, Microsoft Customer Agreement und Microsoft Partner Agreement mit Azure-Plan-Subscriptions zur Verfügung, braucht nach Microsofts Angabe 8 bis 24 Stunden und wirkt für den laufenden Monat ab dessen erstem Tag. Trägt eine Ressource denselben Schlüssel wie ihre Gruppe, gewinnt standardmäßig der Tag der Ressource; das lässt sich umstellen. Nicht jeder Ressourcentyp unterstützt Tags, klassische Ressourcen gar nicht, und Käufe oder Ressourcen, die keine Nutzung auf Subscription-Ebene erzeugen, bekommen auch mit Vererbung keine Tags.

Google Cloud

Google Cloud kennt zwei verschiedene Dinge. Labels sind Metadaten an einer Ressource: bis zu 64 je Ressource, Schlüssel 1 bis 63 Zeichen, Werte bis 63 Zeichen, Kleinbuchstaben, Ziffern, Unterstriche und Bindestriche, internationale Zeichen eingeschlossen. Labels werden an das Abrechnungssystem weitergereicht und stehen in den Abrechnungsberichten und im BigQuery-Export zur Verfügung. Tags dagegen sind eigene Ressourcen, die vor der Nutzung definiert werden, in der Ressourcenhierarchie nach unten vererbt werden und in IAM- und Organisationsrichtlinien als Bedingung dienen; Labels können das nicht. Im Standard-Nutzungsexport landen Labels im Feld labels, die Labels des Projekts getrennt davon in project.labels, von Google erzeugte Systemlabels in system_labels und Tags in tags, mit dem Vermerk, ob die Bindung geerbt ist. Die Kostendaten eines Labels beginnen an dem Tag, an dem es gesetzt wurde, und Tags brauchen laut Google bis zu einer Stunde, bis sie im Export erscheinen. Das Projekt ist davon unabhängig: Seine Labels trägt jede Position, die in ihm anfällt, auch wenn die Ressource selbst nichts trägt.

Was es für Ihre Kosten bedeutet

In den Abrechnungsdaten ist ein Tag eine zusätzliche Spalte oder ein verschachteltes Feld je Position. Ein Kostenbericht gruppiert danach, und die Summe über alle Werte eines Schlüssels plus die Positionen ohne Wert ergibt wieder die Rechnung. Der Anteil mit Wert ist die Tag-Abdeckung, der Rest sind nicht getaggte Kosten, und erst aus dem zugeordneten Anteil lassen sich Stückkosten rechnen.

Hundert Prozent erreicht diese Abdeckung nie, weil ein Teil der Rechnung an keiner Ressource hängt. Support-Pläne, Reservierungskäufe und Commitment-Gebühren werden dem Konto oder Abrechnungsprofil berechnet, nicht einer taggbaren Ressource; Azure zeigt sie in der Kostenanalyse als „Tags not supported“, und bei Google Cloud gehören Support-Kosten zum Abrechnungskonto und tragen kein Projekt. Marketplace-Positionen tragen einen Tag nur dort, wo der Provider sie mit einer getaggten Ressource verknüpft. Datentransfer trägt einen Tag nur, wo der Provider die Position der sendenden Ressource zurechnet. Dazu kommen Services, deren Nutzungsdaten keine Tags enthalten; Azure weist sie als „Tags not available“ aus. Nur was danach übrig bleibt, ist im engeren Sinn ungetaggt und ein Versäumnis des Teams. Ein ehrlicher Bericht trennt diese Gruppen, weil nur die letzte durch Tagging kleiner wird; die anderen brauchen eine Regel, die sie als geteilte Kosten nach Konto, Projekt oder Schlüssel verteilt.

Welche Schlüssel es braucht, ist fast überall dasselbe kleine Set: wer die Ressource verantwortet (owner oder team), in welcher Umgebung sie läuft (environment), zu welchem Produkt oder Service sie gehört (product oder application) und auf welche Kostenstelle sie gebucht wird (cost-center). Mehr Schlüssel heben die Tag-Abdeckung selten, sie senken sie, weil jeder weitere Schlüssel eine weitere Lücke ist.

Wo es schiefgeht

• Tags werden spät aktiviert. Die Ressourcen waren getaggt, aber niemand hat die Schlüssel in der AWS-Konsole aktiviert oder in Azure die Vererbung eingeschaltet. Azure wendet die Vererbung ab dem laufenden Monat an, frühere Monate bleiben ohne die geerbten Tags; AWS füllt frühere Monate nur, wenn das Management-Konto einen Backfill beantragt, für bis zu zwölf Monate und nur für Tags, die die Ressourcen damals trugen.
• Schlüssel in mehreren Schreibweisen. CostCenter, costcenter und cost-center sind bei AWS drei Schlüssel, Google Cloud lässt nur Kleinschreibung zu, und Azure zeigt die Schreibweise, die der Resource Provider behalten hat. Der Bericht hat dann drei Spalten für eine Sache, und jede ist unvollständig.
• Tags auf der falschen Ebene. Ein Tag an der Azure-Ressourcengruppe erreicht die Nutzungsdaten der Ressourcen nur über die Tag-Vererbung in Cost Management oder über eine Azure-Policy-Definition, die ihn an die Ressourcen kopiert (Effekt modify); ein Google-Cloud-Projektlabel steht in einem anderen Feld als die Ressourcenlabels. Wer die Vererbung voraussetzt, misst eine Tag-Abdeckung, die nicht existiert.
• Abdeckung nach Ressourcen statt nach Kosten gezählt. Eine hohe Quote getaggter Ressourcen sagt nichts über den Anteil der Kosten, wenn die wenigen teuersten Datenbanken und Cluster darunter fehlen. Die Tag-Abdeckung wird in Geld gemessen, nicht in Stückzahlen.
• Die Richtlinie kommt vor dem Bericht. Ein Tagging-Standard mit einem Dutzend Pflichtschlüsseln, den niemand gegen einen Kostenbericht liest, erzeugt Pflichtfelder mit Platzhalterwerten. Zuerst der Bericht, dann die Schlüssel, die er braucht, und eine Tag-Abdeckung, die jemand monatlich anschaut.

Quellen

Gelesen am 2026-10-15. AWS Kosten mit Cost Allocation Tags organisieren, Cost Allocation Tags nachträglich füllen, von AWS erzeugte Tags und Grenzen und Regeln für Tag-Namen; Microsoft Azure-Ressourcen mit Tags organisieren, Kosten mit Tag-Vererbung gruppieren, Policy-Definitionen für Tag-Compliance zuweisen und Gruppieren und Filtern in der Kostenanalyse; Google Cloud Überblick über Labels, Überblick über Tags und Struktur des Standard-Datenexports; FinOps Foundation Allocation (CC BY 4.0).