Jeder Jahreswechsel führt mir wieder vor Augen, wie schnell Azure-Umgebungen ausufern, wenn niemand die Tagging-Strategie konsequent durchsetzt. In vielen Tenants, die ich betreue, zeigt sich das Durcheinander spätestens zum Budgetstart: Tags fehlen oder sind uneinheitlich vergeben, von sauberen Kostenstellen ganz zu schweigen. Dabei bietet Azure Policy schon seit Längerem gut brauchbare eingebaute Tag-Funktionen, die genau das verhindern und sogar bestehende Ressourcen nachträglich korrigieren.

Azure Policy erzwingt Pflicht-Tags und vererbt sie an Ressourcen

Die wichtigsten Policy-Vorlagen für Tags liefert Azure bereits fertig mit. Besonders nützlich finde ich „Inherit a tag from the resource group if missing“ für die Vererbung und „Require a tag on resource groups“ als Pflichtfeld auf Resource Groups. Beide gibt es mit „Modify“- und mit „Deny“-Effekt. „Deny“ verhindert, dass jemand neue Ressourcen ohne Tag anlegt. „Modify“ ergänzt fehlende Tags beim Anlegen oder passt Werte an, sofern für das Policy Assignment eine Managed Identity existiert. Aus Erfahrung weise ich Policies möglichst auf Management-Group-Ebene zu, damit tatsächlich der gesamte Scope abgedeckt ist. Die Vererbungs-Policy erleichtert die Arbeit enorm, denn kaum jemand hat Lust, jede Ressource einzeln zu taggen. Einzelheiten dazu stehen auch in der Microsoft-Dokumentation zur Tag-Vererbung.

Bevor man Pflicht- oder Vererbungs-Policies einführt, sollte man sich die vorhandenen Ressourcen genau ansehen, vor allem wenn anschließend eine Remediation ansteht. Im Azure-Portal (Policy → Remediation) lassen sich bei bestehenden Ressourcen die richtigen Tags ergänzen. Dafür muss die Policy den „Modify“-Effekt haben, und es braucht eine System- oder User-Assigned Managed Identity mit Schreibrechten. Wie die Remediation im Einzelnen abläuft, erklärt die Dokumentation zur Remediation.

Drei konsequent gepflegte Tags reichen für den Anfang meist aus

Immer wieder begegnen mir ellenlange Tag-Listen, die im Alltag niemand pflegt. Für den Start ins neue Budgetjahr rate ich deshalb zu einem pragmatischen Ansatz: Einige wenige Tags, die konsequent durchgesetzt werden, genügen in den meisten Fällen. Meine übliche Empfehlung:

  • costcenter (Kostenstelle/Budget)
  • owner (Verantwortlicher)
  • environment (z. B. prod, dev, test)

Mit diesen dreien hat man genug Transparenz für Abrechnung, Zuständigkeiten und Lifecycle, und sie lassen sich fast immer automatisch befüllen. Wer später feiner unterscheiden möchte, etwa nach Projektname oder Datenschutzklassifizierung, kann das Schritt für Schritt ergänzen. Weitere Hinweise zur Governance-Strategie in Azure gibt es direkt bei Microsoft.

Praktischer Tipp: Für die Modify-Policies und die Tag-Vererbung lege ich pro Management Group grundsätzlich eine zentrale Managed Identity an und gebe ihr Contributor-Rechte. So gibt es bei der Remediation später keine Probleme mit der Zuordnung.

Die Tag-Vererbung im Cost Management ersetzt keine Policy

Viele stolpern über folgenden Punkt: Nicht jedes in Azure vergebene Tag landet automatisch in den Abrechnungsdaten. Das Cost Management bietet dafür die Funktion „Tag inheritance“ (Azure-Portal → Cost Management → Settings → Tag inheritance). Sie übernimmt die Tags der Resource Group auch in die Kostenansicht der darin enthaltenen Ressourcen. Damit lassen sich bestehende Inkonsistenzen gut abfedern, sauberes Tagging über Policies ersetzt das aber nicht. Richtlinien setzen Tags technisch zuverlässig durch. Die Tag-Inheritance im Cost Management ist dagegen eher Kosmetik und wirkt sich nur auf das Reporting aus.

Eine Remediation räumt die Altlasten nachträglich auf

Solange die Altlasten bleiben, bringt auch die beste Policy wenig. Nach der Einführung stoße ich deshalb jedes Mal eine Remediation an. Im Azure-Portal unter Policy → Remediation kann man für jede Policy eine Aufgabe anlegen, die bestehende Ressourcen mit fehlenden oder falschen Tags korrigiert. Auch hier braucht es den „Modify“-Effekt und eine Managed Identity mit passenden Rechten. In großen Tenants dauert das mitunter eine Weile. Danach steht aber endlich eine solide Basis für vernünftige Berichte und Kostenauswertungen.

Eine KQL-Abfrage zeigt die Ressourcen mit fehlenden Tags

Um herauszufinden, wo noch nachgearbeitet werden muss, eignet sich der Azure Resource Graph Explorer (Azure-Portal → Resource Graph Explorer). Mit einer einfachen KQL-Abfrage findet man dort gezielt Ressourcen ohne Tags. Benötigt werden lediglich Leserechte auf den betreffenden Subscriptions.

// Azure Resource Graph Explorer
Resources
| where isnull(tags["costcenter"]) or isnull(tags["owner"]) or isnull(tags["environment"])
| project name, type, resourceGroup, subscriptionId

Die Abfrage listet sämtliche Ressourcen auf, denen mindestens eines der drei Basis-Tags fehlt. Nach der ersten Runde mit Policies und Remediation ist das sehr hilfreich, um verbliebene Lücken zu finden und gezielt zu schließen.

Gerade das Zusammenspiel von Vererbung, Pflichtfeldern und Remediation versteht man mit einer Grafik leichter. Das folgende Diagramm zeigt, an welcher Stelle die Tagging-Policies greifen und wo die Remediation ansetzt:

flowchart TD
MG["Management Group"] --> P1["Policy: Tag vererben"]
P1 --> RG["Resource Group"]
RG --> P2["Policy: Tag erforderlich"]
P2 --> Res["Resource"]
Res --> Rem["Remediation"]

Abbildung: Zusammenspiel von Tagging-Policies und Remediation über Management Group, Resource Group und Ressourcen

Wenige Tags bringen mehr, wenn man sie konsequent durchsetzt

Selbst die durchdachteste Tagging-Strategie verpufft, wenn sie nicht technisch erzwungen und auch auf den Altbestand angewendet wird. Mit Azure Policy, Remediation und gezielten KQL-Abfragen habe ich in den vergangenen Tagen wieder einige Umgebungen in Rekordzeit auf Linie gebracht. Entscheidend ist für mich eine kurze, sinnvolle Tag-Liste, die man konsequent umsetzt, dazu Vererbungs-Policies auf Management-Group-Ebene. Wer zusätzlich regelmäßig eine Remediation anstößt und die Tag-Inheritance im Cost Management als Ergänzung betrachtet, startet aufgeräumt ins neue Budgetjahr und muss sich beim nächsten Kostenreport nicht mehr schämen.