---
title: "Entwicklung einer Tagging-Strategie"
description: "Wie Organisationen eine Cloud-Tagging-Strategie methodisch entwickeln: die vier Dimensionen eines Tagging-Frameworks, Workshop-Methodik, Governance-Ownership und ein phasenweiser Rollout-Ansatz."
sidebar:
order: 2
label: "Tagging-Strategie"
source_url: "https://framework.stackit.cloud/de/advisory/cloud-finance-management/tagging-strategy/"
source_file: "docs/de/advisory/cloud-finance-management/tagging-strategy.mdx"
---
## Warum Tagging eine Governance-Entscheidung ist und keine Konfigurationsaufgabe
Tags sind Kennzeichnungen, die an Cloud-Ressourcen angebracht werden. Aber zu entscheiden, welche Tags obligatorisch sind, welche Werte gültig sind, wer für ihre Pflege verantwortlich ist und wie die Einhaltung durchgesetzt wird — das sind Governance-Entscheidungen. Und wie bei den meisten Governance-Entscheidungen ist die technische Umsetzung der leichte Teil.
Organisationen, die das Tagging als Konfigurationsaufgabe betrachten, enden mit Tag-Schemata, die nie konsequent angewendet wurden, Kostenberichten, denen niemand vertraut, und Compliance-Lücken, die bei jedem Audit Probleme verursachen. Organisationen, die es als Governance-Entscheidung angehen, kommen zu einem System, das tatsächlich funktioniert — weil die Personen, die es anwenden müssen, verstehen, warum es existiert, und die Regeln akzeptieren.
## Die vier Dimensionen eines Tagging-Frameworks
Ein Tagging-Framework ist mehr als eine Liste von Tag-Schlüsseln. Es deckt vier Dimensionen ab, die zusammen entscheiden, ob das System in der Praxis funktioniert.
**Was wird getaggt?** Nicht jede Ressource muss jedes Tag tragen. Das Framework definiert, welche Ressourcentypen welche Tags benötigen — wobei zwischen Kernressourcen (VMs, Storage, Datenbanken) und unterstützenden Ressourcen (Netzwerkkonfigurationen, Sicherheitsregeln) unterschieden wird. Diese Unterscheidung verhindert Tag-Ermüdung: Teams werden nicht gebeten, 20 Tags auf einer Firewall-Regel zu pflegen.
**Welche Werte sind gültig?** Freitextwerte in Tags sind der Anfang vom Ende. „dev“, „Dev“, „development“, „Development“ und „DEV“ bedeuten alle dasselbe — aus Sicht der Kostenberichterstattung und der Automatisierung handelt es sich jedoch um vier verschiedene Werte. Ein gutes Rahmenwerk definiert zulässige Werte, wo immer möglich, pro Tag und macht Abweichungen sichtbar.
**Wer ist verantwortlich?** Jedes Tag hat einen Eigentümer: jemanden, der entscheidet, was das Tag bedeutet, die Liste gültiger Werte verwaltet und Ausnahmen behandelt. Ohne klare Verantwortlichkeit bauen sich Tags lautlos ab — niemand bemerkt, wenn Werte inkonsistent werden, weil niemand zuschaut.
**Wie wird Compliance durchgesetzt?** Die Durchsetzung hat zwei Dimensionen: Was passiert, wenn eine nicht konforme Ressource erstellt wird, und wie eine bestehende Nicht-Konformität identifiziert und behoben wird. Beide benötigen eine definierte Antwort, bevor die erste Leitplanke aktiviert wird.
## Workshop-Methodik: zu einem Tag-Schema kommen, das bleibt
Ein Tag-Schema, das funktioniert, ist eines, das in Zusammenarbeit mit den Personen entworfen wurde, die es anwenden. Tags, die isoliert von einem zentralen Team entwickelt und dann an alle Teams mandatiert werden, neigen zum Scheitern: Entweder entsprechen sie nicht den realen Anforderungen, oder Teams verstehen ihren Zweck nicht und wenden sie inkonsistent an.
Das beste Tag-Schema leitet sich aus den Reporting- und Governance-Anforderungen ab, die es
erfüllen muss. Welche Kostenverrechnungsberichte benötigen wir? Wer muss Compliance-Ownership
nachweisen? Was muss durch die automatisierte Behebung erkannt werden? Diese Fragen bestimmen
die Tags — nicht umgekehrt.
Plattform-Team, FinOps, Security und mindestens zwei Anwendungsteams sollten im Raum sein.
Teams, die beim Entwerfen des Schemas helfen, verstehen seinen Zweck und wenden ihn konsequent
an. Teams, die von oben ein Mandat erhalten, wenden es ungern an — und uneinheitlich.
Gültige Werte sollten widerspiegeln, wie die Organisation tatsächlich funktioniert — nicht, wie
sie idealerweise funktionieren sollte. Ein Kostenstellen-Tag, das einen Code benötigt, den drei
Teams noch nicht haben, wird vom ersten Tag an drei nicht konforme Teams erzeugen. Arbeiten Sie
mit Finance zusammen, um sicherzustellen, dass die gültigen Werte in den Systemen vorhanden
sind, wo dies erforderlich ist.
Jeder Tag-Schlüssel benötigt eine Beschreibung: Was bedeutet er, warum wird er benötigt, was
sind die gültigen Werte, wem gehört er? Teams ziehen diese Dokumentation heran, wenn sie sich
nicht sicher sind. Ohne sie sind Tags Rätselraten.
## Drei-Phasen-Rollout: von der Pilotierung bis zum Enforcement
Die effektivsten Tag-Rollouts fangen klein an und erweitern sich basierend auf Evidenz — nicht auf einem Big-Bang-Mandat, das eher Compliance-Theater als echte Compliance schafft.
Die erste Phase ist Audit-only: Überwachung ohne Erzwingung. Neue und bestehende Ressourcen werden gegen das Tag-Schema geprüft. Verstöße sind sichtbar, blockieren aber nichts. Diese Phase erstellt ein Bild des aktuellen Zustands und gibt den Teams Zeit, das Schema zu verstehen und anzuwenden, bevor es Konsequenzen hat.
In der zweiten Phase wird ein Soft Enforcement für neue Ressourcen eingeführt: Ressourcen ohne obligatorische Tags lösen eine Benachrichtigung aus. Die Teams werden informiert, erhalten Unterstützung bei der Behebung und erhalten einen Zeitplan. Dadurch soll verhindert werden, dass sich neue Verstöße häufen, während bestehende Verstöße angegangen werden.
Die dritte Phase erreicht die vollständige Durchsetzung: Nicht konforme neue Ressourcen werden blockiert. Bestehende Verstöße wurden behoben oder explizit als Ausnahme anerkannt. Das Tag-Schema ist nun eine echte Governance-Kontrolle, kein Anspruch.
## Der Tag-Katalog: Pflichtfelder und erlaubte Werte
Ein Tag-Katalog definiert, welche Tags für jede Cloud-Ressource obligatorisch sind — und welche Werte erlaubt sind. Ohne definierte Wertesätze werden Tags zu einem Freitextfeld, das niemand filtern, auswerten oder automatisch erzwingen kann.
Fünf obligatorische Tags bilden den Mindeststandard für eine steuerbare Cloud-Umgebung:
**`environment`** — Die Betriebsumgebung der Ressource. Ermöglicht eine eindeutige Zuordnung von Ressourcen zu Lebenszyklus und Betriebsphasen.
| Wert | Bedeutung |
| --------- | -------------------------------------------------------------------------------------------------------- |
| `prod` | Produktionsumgebung, die von Endanwendern oder Geschäftsprozessen genutzt wird |
| `dev` | Entwicklungsumgebung für neue Features und initiale Validierung |
| `test` | Testumgebung für funktionales, technisches oder automatisiertes Testen |
| `qa` | Qualitätssicherung vor der weiteren Freigabe einer Lösung |
| `stage` | Produktionsnahe Validierung vor der Produktivbereitstellung |
| `uat` | User Acceptance Testing durch fachliche Nutzer oder Stakeholder |
| `demo` | Demonstrationsumgebung für Kunden, Schulungen oder interne Demos |
| `archive` | Archivierte oder stillgelegte Ressourcen, die weiterhin für Audit oder Wiederherstellung benötigt werden |
| `int` | Integrationsumgebung für Schnittstellen- und End-to-End-Tests |
| `sandbox` | Experimentieren und Bewerten außerhalb definierter Entwicklungsprozesse |
**`provisioned-by`** — Wie die Ressource erstellt wurde. Dieses Tag ermöglicht die Erkennung von Ressourcen, die außerhalb des IaC-Prozesses erstellt wurden — ein kritisches Governance-Signal.
| Wert | Bedeutung |
| ---------- | ------------------------------------------------------------------------------------------------ |
| `iac` | Bereitstellung über Infrastructure as Code (Terraform, OpenTofu, Pulumi, Bicep, CloudFormation) |
| `portal` | Erstellt über ein Webportal oder eine grafische Verwaltungsoberfläche |
| `cli` | Bereitstellung über eine Befehlszeilenschnittstelle |
| `sdk` | Bereitstellung über das SDK eines Cloud-Anbieters |
| `rest-api` | Direkte Bereitstellung über die REST-API des Cloud-Anbieters |
Ressourcen mit dem Tag `portal` oder `cli` in einer Produktionsumgebung signalisieren, dass jemand den IaC-Prozess umgangen hat — genau die Governance-Sichtbarkeit, die dieses Tag bieten soll.
**`cost-center`** — Die organisatorische Einheit, die die Kosten trägt. Der Wert muss eine gültige Kennung aus dem maßgeblichen Finanz- oder ERP-System sein. Es sind nur genehmigte Kostenstellenkennzeichen erlaubt.
**`data-classification`** — Die Vertraulichkeit der Daten, die von der Ressource verarbeitet, gespeichert oder übertragen werden. Steuert Sicherheitskontrollen, Verschlüsselungsanforderungen und Zugriffsbeschränkungen.
| Wert | Bedeutung |
| -------------- | ------------------------------------------------------------------------------------------------ |
| `public` | Öffentliche oder nicht klassifizierte Informationen, die zur Veröffentlichung vorgesehen sind |
| `internal` | Interne Informationen für Mitarbeitende, Partner oder beauftragte Dritte |
| `restricted` | Erhöhter Schutzbedarf; unerlaubte Weitergabe verursacht erhebliche Auswirkungen |
| `confidential` | Hoher Schutzbedarf; unerlaubte Weitergabe hat gravierende Folgen |
| `secret` | Sehr hoher Schutzbedarf; Offenlegung verursacht kritische Konsequenzen |
| `top-secret` | Höchste Klassifizierung; Offenlegung hat existenzielle oder katastrophale Folgen |
**`application-id`** — Die eindeutige Kennung der Anwendung aus der CMDB oder dem Anwendungsregister. Dieses Tag stellt die nachvollziehbare Verbindung von Cloud-Ressource zur Business-Applikation her.
Für den gesamten Tag-Katalog gelten zwei Grundsätze: Tags verweisen auf Informationen, sie duplizieren diese nicht. Ein Tag zeigt auf das autoritative System, anstatt seine Daten inline zu reproduzieren. Und Tags ersetzen nie eine CMDB — sie verweisen darauf. Die CMDB enthält den vollständigen Anwendungskontext; das Tag stellt lediglich die Verbindung her.
## Was gelingt — was misslingt
Wenige, aussagekräftige Tags mit klarer Verantwortlichkeit. Gültige Werte im Voraus definiert.
Enforcement sukzessive eingeführt. Teams, die am Design beteiligt sind. Ausnahmen werden durch
einen definierten Prozess behandelt, keine Ad-hoc-Übersteuerungen.
Zu viele Tags, die niemand versteht. Freitextwerte, die Berichte fragmentieren.
Big-Bang-Durchsetzung, die Teams blockiert, bevor sie das Schema verstehen. Tags, die allein vom
Plattform-Team definiert werden, ohne Zutun derer, die sie anwenden.
## Einführung in fünf Schritten
1. **Reporting-Anforderungen definieren:** Welche Fragen soll das Tag-Schema beantworten? Kosten nach Team, Umgebung, Projekt, Datenklassifizierung — diese Anforderungen bestimmen das Tag-Design, nicht abstrakte Best Practices.
2. **Das Schema gemeinsam entwerfen:** Workshop mit Plattform-Team, FinOps, Security und repräsentativen Anwendungsteams. Definieren Sie Tag-Schlüssel, gültige Werte, Ownership und den Zweck jedes Tags.
3. **Dokumentieren und kommunizieren:** Jedes Tag erhält eine Beschreibung. Das Schema wird dort veröffentlicht, wo es von allen Teams zu finden ist. Teams, die Tags anwenden müssen, wissen warum — und nicht nur was.
4. **Audit-only-Phase:** Überwachung ohne Erzwingung aktivieren. Den aktuellen Stand verstehen. Teams bei der Behebung bestehender Verstöße unterstützen. Gültige Werte auf Basis des Gelernten verfeinern.
5. **Phasenweise Durchsetzung:** Aktivieren Sie die Durchsetzung, indem Sie mit den kritischsten Ressourcen beginnen. Behandeln Sie Ausnahmen anhand eines definierten Prozesses. Bauen Sie auf Vollabdeckung aus.
Wie das Tag-Schema in die Kostenberichterstattung und -optimierung integriert wird, wird in **[Showback & Chargeback](/de/advisory/cloud-finance-management/showback-chargeback)** behandelt.