Policy as Code heißt, Governance-Regeln wie Pflicht-Tags, erlaubte Regionen oder Instanzgrößen als maschinenlesbare Definitionen zu schreiben, in einem Repository zu halten, wie Code zu prüfen und über eine Pipeline auszurollen. Für das Tagging bedeutet das: Die Tagging-Richtlinie wird zu Definitionen, die eine falsch getaggte Ressource beim Anlegen ablehnen, einen fehlenden Tag ergänzen oder den Verstoß melden. Welche Schlüssel und Werte die Richtlinie enthält, beschreibt Tagging-Strategie: eine Richtlinie, die hält. Diese Seite behandelt, mit welchen Mechanismen AWS, Azure und Google Cloud sie durchsetzen und welche Lücke jeder davon lässt.
So funktioniert es
Die Mechanismen greifen an verschiedenen Stellen.
| Mechanismus | Greift | Fehlender Pflicht-Tag | Falscher Wert oder Schreibweise | Bestand |
|---|---|---|---|---|
AWS Tag Policy, Basisregeln mit enforced_for | beim Tagging-Vorgang | nicht verhindert | verhindert, für unterstützte Ressourcentypen | Compliance-Bericht |
| AWS Tag Policy, „Required tag key“ | im Deployment über CloudFormation, Terraform oder Pulumi | Warnung oder Abbruch | nur der Schlüssel wird geprüft | organisationsweiter Bericht |
SCP mit aws:RequestTag | bei der API-Anfrage | verhindert, wo der Dienst Tags beim Anlegen annimmt | Werte ja, Schreibweise des Schlüssels nein | nein |
AWS Config required-tags | nach Konfigurationsänderungen | gemeldet | Werte gemeldet | ja |
| Azure Policy deny | bei der Anfrage | verhindert | Wert verhindert, wenn die Definition ihn prüft; Schreibweise nur mit match | als nicht konform markiert |
| Azure Policy modify | bei der Anfrage, Bestand per Remediation-Task | ergänzt | ersetzt | per Remediation-Task |
| Google Custom Constraint | beim Anlegen, wahlweise auch beim Ändern | verhindert | verhindert, wenn die Bedingung den Wert prüft | nicht rückwirkend |
AWS
Tag Policies in AWS Organizations legen je Schlüssel die Schreibweise und die zulässigen Werte fest. Mit enforced_for verhindern sie nicht konforme Tagging-Vorgänge für die genannten Ressourcentypen. AWS schreibt aber, dass diese Basisregeln Ressourcen, die ohne Tags angelegt werden, nicht erfassen und fehlende Schlüssel nicht erzwingen. Dafür verweist AWS auf zwei andere Wege. Der erste ist „Required tag key“: Mit report_required_tag_for wird ein Schlüssel für Ressourcentypen als Pflicht markiert, und Deployments prüfen das vor dem Anlegen, in CloudFormation über den Hook AWS::TagPolicies::TaggingComplianceValidator im Modus Warn oder Fail, in Terraform ab dem AWS Provider 6.22.0 und in Pulumi über ein Policy Pack. Der Hook muss in jedem Konto und jeder Region aktiviert werden, in denen er gelten soll; AWS nennt dafür StackSets. Der zweite Weg ist eine SCP, die das Anlegen bestimmter Ressourcentypen ohne die verlangten Tags verweigert, über die Bedingungen aws:RequestTag und aws:TagKeys. Schlüsselnamen in solchen Bedingungen unterscheiden Groß- und Kleinschreibung nicht; gegen Varianten wie CostCenter und costcenter empfiehlt AWS aws:TagKeys oder Tag Policies.
Der Compliance-Bericht der Tag Policies enthält nur Ressourcen, die irgendwann mindestens einen eigenen Tag hatten; ungetaggte Ressourcen erscheinen nicht als nicht konform. AWS verweist für sie auf Resource Explorer mit der Abfrage tag:none. Die Config-Regel required-tags prüft bis zu sechs Schlüssel mit optionalen Werten für eine feste Liste von Ressourcentypen, löst bei Konfigurationsänderungen aus und verhindert nichts; eine automatische Korrektur braucht ein eigenes Systems-Manager-Dokument.
Azure
In Azure Policy entscheidet der Effekt. Deny lehnt die Anfrage ab, audit protokolliert sie, append fügt Felder nur bei neuen oder geänderten Ressourcen hinzu, und modify ergänzt, ersetzt oder entfernt Tags beim Anlegen oder Ändern. Vorhandene Ressourcen ändert modify nur über einen Remediation-Task, für den die Zuweisung eine verwaltete Identität mit den Rechten von Contributor oder Tag Contributor braucht; Microsoft empfiehlt für Tags modify statt append. Modify wird vor deny ausgewertet, ein ergänzter Tag kann ein deny also verhindern. Eingebaut sind etwa „Require a tag on resources“ (deny) und „Inherit a tag from the resource group if missing“ (modify). Bedingungen in Policy-Regeln ignorieren Groß- und Kleinschreibung, außer bei match und notMatch; Prod besteht also eine Regel, die prod erwartet.
Davon zu unterscheiden ist die Tag-Vererbung in Cost Management für EA, MCA und MPA. Sie schreibt Tags von Subscription und Ressourcengruppe in die Nutzungsdatensätze, nicht an die Ressourcen, innerhalb von acht bis 24 Stunden und für den laufenden Monat.
Google Cloud
Organisationsrichtlinien prüfen Labels über Custom Constraints mit Bedingungen in CEL. Für Compute-Engine-Instanzen unterstützt Google unter anderem resource.labels und resource.machineType, etwa 'cost_center' in resource.labels. Ein Constraint gilt für den Ressourcentyp, für den er geschrieben ist, beim Anlegen oder zusätzlich beim Ändern; im zweiten Fall blockiert er Änderungen an einer regelwidrigen Ressource, bis die Änderung den Verstoß behebt. Google bietet einen Dry-Run-Modus zum Testen, und neue Richtlinien wirken in der Regel nicht rückwirkend. In Preview kann eine eigene Organisationsrichtlinie außerdem Tags des Resource Managers für aufgeführte Ressourcentypen verlangen, darunter Projekte und Compute-Engine-Instanzen. Anders als Labels werden Tags des Resource Managers vererbt und lassen sich in IAM-Bedingungen und für einige Ressourcen in Bedingungen von Organisationsrichtlinien verwenden; beide erreichen den Abrechnungsexport, Tags mit dem Feld tags.inherited.
Definitionen im Repository
Microsoft beschreibt den Ablauf so: Definitionen, Zuweisungen und Ausnahmen liegen als JSON in der Versionsverwaltung, GitHub-Workflows oder Azure Pipelines rollen sie aus, und Schreibrechte auf Policy-Ressourcen lassen sich auf die Identität der Pipeline beschränken. Eine neue Regel läuft zuerst mit abgeschaltetem Enforcement Mode in einer Testumgebung; es folgen Compliance-Prüfung, Remediation und das Erzwingen, Umgebung für Umgebung. Google setzt Organisationsrichtlinien als YAML-Dateien mit gcloud org-policies set-policy und prüft mit gcloud beta terraform vet, in Preview, Terraform-Pläne in der CI-Pipeline gegen Constraints.
Open-Source-Werkzeuge gibt es in zwei Kategorien. Eine Policy-Engine wie Open Policy Agent, ein Graduated-Projekt der CNCF, prüft den Terraform-Plan als JSON mit Regeln in Rego, bevor er angewandt wird. Eine Regel-Engine wie Cloud Custodian filtert laufende Ressourcen bei AWS, Azure und Google Cloud mit YAML-Regeln und wendet Aktionen an; die Dokumentation des Projekts zeigt eine Regel, die ungetaggte EC2-Instanzen markiert und später stoppt.
Was es für Ihre Kosten bedeutet
Durchsetzung beim Anlegen hält den Zuordnungsgrad stabil, wenn neue Teams, Konten und Projekte dazukommen. Keiner der Mechanismen in der Tabelle deckt allein alles ab, eine tragfähige Einrichtung kombiniert deshalb eine präventive Regel für neue Ressourcen, eine detektive Prüfung des Bestands und die Messung in Geld, wie Tag-Abdeckung und nicht getaggte Kosten sie beschreibt.
Ob ein Tag an der Ressource stehen muss oder nur in den Kostendaten, entscheidet über den Aufwand. Für die Kostenzuordnung kann die Tag-Vererbung von Azure genügen, und bei Google erscheinen vererbte Tags im Export. Automatisierung und Zugriffsregeln lesen dagegen den Tag an der Ressource. Wann ein nachträglich gesetzter Tag in den Abrechnungsdaten erscheint, unterscheidet sich je Provider (Tags und Labels). Wo die Richtlinie in die Kostenrichtlinie insgesamt passt, beschreibt Kostenrichtlinie: Inhalt, Durchsetzung, Ausnahmen.
Wo es schiefgeht
- Erzwungen und trotzdem ungetaggt. Symptom: Die Tag Policy steht auf
enforced_for, dennoch entstehen Ressourcen ohne Kostenstelle. Ursache: Die Basisregeln prüfen nur gesetzte Tags und erzwingen keine fehlenden Schlüssel. - Zwei Schreibweisen trotz SCP. Symptom:
CostCenterundcostcenterstehen beide in den Daten, obwohl eine SCP den Tag verlangt. Ursache: Schlüsselnamen in IAM-Bedingungen unterscheiden Groß- und Kleinschreibung nicht. - Modify ohne Remediation. Symptom: Neue Ressourcen tragen den Tag, alte nicht, und die Abdeckung bleibt stehen. Ursache: Der Bestand ändert sich nur über einen Remediation-Task mit verwalteter Identität.
- Regel für einen einzigen Dienst. Symptom: Google-VMs tragen Labels, andere Ressourcen nicht. Ursache: Ein Custom Constraint gilt nur für den Ressourcentyp, für den er geschrieben ist.
- Vererbung verwechselt. Symptom: Die Kostenanalyse gruppiert sauber nach Tag, eine Automatisierung findet ihn an der Ressource nicht. Ursache: Die Tag-Vererbung von Cost Management schreibt in die Nutzungsdaten, nicht an die Ressource.
Quellen
Gelesen am 2026-10-16. AWS Tag Policies, Tagging-Konsistenz erzwingen, „Required tag key“ mit IaC erzwingen, Tagging-Compliance berichten, Service Control Policies, Zugriff über Tags steuern und Config-Regel required-tags; Microsoft Grundlagen der Policy-Effekte, Modify-Effekt, Policy-Definitionen für Tags, Tag-Vererbung in Cost Management, Azure Policy as Code und Bedingungen in Policy-Regeln; Google Cloud Custom Constraints für Compute Engine, Organization Policy Service, Ressourcenstandorte einschränken, Tags im Überblick, Struktur des Standard-Datenexports und Richtlinienprüfung für Terraform; Open Policy Agent Dokumentation und Terraform; Cloud Custodian Projektseite und Tag-Compliance über Ressourcen.