Tagging-Strategie: eine Richtlinie, die hält

Eine Tagging-Strategie in der Cloud ist eine schriftliche Tagging-Richtlinie: Sie legt fest, welche Schlüssel Pflicht sind, welche Werte zulässig sind, wie Schlüssel geschrieben werden, an welchen Ressourcen sie stehen müssen und wer die Liste pflegt. Ein einzelner Tag ordnet noch keine Kosten zu. Erst wenn alle Teams denselben Schlüssel in derselben Schreibweise und mit Werten aus derselben Liste setzen, gruppiert ein Kostenbericht sauber nach Team, Produkt oder Kostenstelle. Ohne Richtlinie zerfällt ein Merkmal in mehrere Spalten, und der Zuordnungsgrad bleibt niedrig, obwohl getaggt wird. Wie Tags in die Abrechnungsdaten gelangen und welche Längen- und Zeichengrenzen gelten, beschreibt Tags und Labels; diese Seite behandelt die Regeln darüber.

So funktioniert es

AWS, Microsoft und Google beschreiben dieselben Bestandteile. AWS schreibt ein Tagging-Schema, eine Tabelle der Schlüssel mit zulässigen Werten, Ressourcentypen und Geltungsbereich, abgelegt in einem versionierten Repository. Microsoft setzt im Cloud Adoption Framework eine Namenskonvention voraus und unterscheidet Tags für Betrieb, Klassifizierung, Buchhaltung, Zweck und Verantwortung. Google empfiehlt eine formale Labeling-Richtlinie, die je Schlüssel die Werte, den Stakeholder, die Zielressource und die Ausnahmen festhält.

Was die Leitfäden festlegen

Pflichtschlüssel und Werte

In den Beispielen aller drei Provider tauchen dieselben Merkmale auf: wer die Ressource verantwortet (owner oder team), in welcher Umgebung sie läuft (environment), zu welcher Anwendung oder welchem Produkt sie gehört (application) und auf welche Kostenstelle sie gebucht wird (cost-center). Für jeden Pflichtschlüssel braucht die Richtlinie eine Werteliste oder eine Wertequelle. Für Umgebungen genügt eine feste Liste. Kostenstellen und Teams ändern sich mit der Organisation; hier kann die Richtlinie auf das System verweisen, das sie führt, etwa die Kostenstellenliste der Buchhaltung. Wie Team und Kostenstelle zueinander stehen, beschreibt Kostenstellen und Verantwortung im Team.

Eine Schreibweise für drei Provider

Wer dieselben Schlüssel bei allen drei Anbietern setzt, ist an die engste Regel gebunden, und das ist die von Google: Label-Schlüssel beginnen mit einem Kleinbuchstaben oder internationalen Zeichen und enthalten nur Kleinbuchstaben, Ziffern, Unterstriche und Bindestriche. Die Präfixe mit Doppelpunkt aus dem AWS-Leitfaden, etwa example-inc:cost-allocation:CostCenter, lassen sich als Google-Label nicht setzen. Bei AWS sind costcenter und CostCenter zwei Schlüssel, und AWS weist selbst darauf hin, dass auch die Rechtschreibung trennt: costcenter und das britische costcentre sind verschiedene Schlüssel. Azure behandelt Namen bei Operationen ohne Rücksicht auf Groß- und Kleinschreibung, zeigt in den Kostenberichten aber die gespeicherte Schreibweise. Für eine Richtlinie über mehrere Provider folgt daraus: Schlüssel in Kleinbuchstaben mit einer einzigen Art von Trennzeichen, einmal ausgeschrieben, und Listenwerte in derselben Form.

Ebene und Durchsetzung

Die Richtlinie legt je Schlüssel fest, wo er steht. Ein Merkmal, das für eine ganze Subscription oder ein ganzes Projekt gilt, kann dort sitzen. Bei Azure erreicht es die Nutzungsdaten der Ressourcen dann über die Tag-Vererbung in Cost Management oder über eine Azure-Policy-Definition, die den Tag von Ressourcengruppe oder Subscription an die Ressourcen kopiert (Effekt modify); bei Google Cloud steht es als Projektlabel in einem eigenen Feld des Exports. Was je Ressource wechselt, steht an der Ressource.

Durchgesetzt wird die Richtlinie außerhalb der Abrechnung. AWS Organizations bildet sie als Tag Policy ab, die zulässige Werte und die bevorzugte Groß- und Kleinschreibung je Schlüssel festlegt und nicht konforme Tagging-Vorgänge für ausgewählte Ressourcentypen verhindern kann. Für einen als Pflicht markierten Schlüssel können CloudFormation, Terraform und Pulumi ein Deployment prüfen, bevor seine Ressourcen entstehen, und bei fehlendem Schlüssel warnen oder es blockieren. Azure Policy bringt eingebaute Definitionen, die einen Tag verlangen (Effekt deny), ergänzen oder von Ressourcengruppe oder Subscription übernehmen (Effekt modify). Präventive und detektive Kontrollen dieser Art beschreibt Guardrails und Freigabeschwellen.

Was es für Ihre Kosten bedeutet

In den Abrechnungsdaten zeigt sich eine Richtlinie als wenige Tag-Spalten, deren Werte aus bekannten Listen stammen. Ein Kostenbericht gruppiert danach ohne Nacharbeit, und jeder Wert außerhalb der Liste fällt als eigene Gruppe auf. Die Richtlinie bestimmt auch, was gemessen wird: Die Abdeckung wird je Pflichtschlüssel in Geld bestimmt, wie Tag-Abdeckung und nicht getaggte Kosten beschreibt.

Jede Änderung hinterlässt eine Spur in der Historie. Ein umbenannter Schlüssel ist bei AWS ein neuer Schlüssel, der als Cost Allocation Tag aktiviert werden muss, und die vergangenen Monate tragen den alten. Ein Backfill, den das Management-Konto für bis zu zwölf Monate beantragen kann, füllt nur Tags, die die Ressourcen damals trugen. Alter und neuer Schlüssel lassen sich deshalb nur über eine Regel verbinden, die beide liest; das beschreibt Virtuelle Tags und Zuordnungsregeln.

Wer die Liste pflegt, ist eine Rollenfrage. AWS schlägt vor, die Verantwortung für das Schema etwa in einer RACI-Matrix festzuhalten; die Rollen selbst behandelt FinOps-Rollen und Verantwortlichkeiten.

Ein Owner-Tag mit dem Namen oder der E-Mail-Adresse einer Person steht in jedem Kostenexport und in jedem Bericht, der die Spalte zeigt. Alle drei Provider raten davon ab, personenbezogene Daten in Tags zu speichern, und Microsoft weist darauf hin, dass Tags als Klartext in Kostenberichten, API-Antworten, Bereitstellungsverläufen und Logs sichtbar sind. Ob ein solcher Wert nach der DSGVO zulässig ist, beurteilt, wer im Unternehmen für den Datenschutz zuständig ist; ein Team- oder Rollenname enthält keinen Personennamen.

Wo es schiefgeht

• Zwei Rechtschreibungen eines Schlüssels. Symptom: costcenter und costcentre stehen als zwei Spalten im Bericht, jede unvollständig. Ursache: AWS unterscheidet Schlüssel nach jedem Zeichen, und die Richtlinie hat die Schreibweise nicht ausgeschrieben.
• AWS-Vorlage auf Google Cloud übertragen. Symptom: Der Schlüssel lässt sich als Label nicht setzen, und Teams weichen auf eigene Varianten aus. Ursache: Google-Labels erlauben weder Doppelpunkte noch Großbuchstaben.
• Freitext statt Werteliste. Symptom: prod, Prod und production erscheinen als drei Umgebungen. Ursache: Werte unterscheiden bei AWS und Azure die Groß- und Kleinschreibung, und ohne Liste schreibt jedes Team seine eigene Form.
• Konform gemeldet, trotzdem ungetaggt. Symptom: Der Compliance-Bericht der Tag Policy ist sauber, der Zuordnungsgrad niedrig. Ursache: Der Compliance-Bericht von AWS führt nur Ressourcen, die mindestens einmal einen Tag hatten, und meldet einen fehlenden Schlüssel nur, wo die Tag Policy ihn für den Ressourcentyp als Pflicht markiert; eine Ressource, die nie getaggt war, erscheint nicht als nicht konform.
• Personen im Owner-Tag. Symptom: E-Mail-Adressen stehen in jedem Kostenexport und in Berichten für die ganze Organisation. Ursache: Die Richtlinie lässt Personenwerte zu, obwohl Tags überall als Klartext sichtbar sind.

Quellen

Gelesen am 2026-10-16. AWS Best Practices for Tagging AWS Resources, daraus Was sind Tags?, Eine Tagging-Strategie aufbauen und Ein Tagging-Schema festlegen und veröffentlichen, Tag Policies in AWS Organizations, Tagging-Compliance auswerten, Pflicht-Tag-Schlüssel mit IaC durchsetzen und Cost Allocation Tags nachträglich füllen; Microsoft Tagging-Strategie festlegen, Tags zum Organisieren von Azure-Ressourcen verwenden, Kosten mit Tag-Vererbung gruppieren und Policy-Definitionen für Tag-Compliance; Google Cloud Best Practices für Labels und Struktur des Standard-Datenexports.