Pexon Consulting | 9 Min. Lesezeit | 26.03.2026


TL;DR

Ohne Governance wird Azure schnell zum Kostengrab mit Sicherheitslücken. Unternehmen mit 300 bis 3.000 Mitarbeitenden brauchen kein überladenes Framework — sondern Management Groups, Azure Policy as Code und eine saubere Landing Zone. Dieser Artikel zeigt mit konkreten Code-Beispielen, wie Sie Governance aufsetzen, bevor die Probleme kommen.


Warum Azure-Umgebungen ohne Governance eskalieren

32 Prozent der Cloud-Ausgaben werden verschwendet — durch vergessene VMs, überdimensionierte Instanzen und Subscriptions, die niemand mehr zuordnen kann. Das belegt der Flexera State of the Cloud Report 2026. Bei einem mittelständischen Unternehmen mit 50.000 Euro monatlichen Azure-Kosten sind das 16.000 Euro, die jeden Monat verbrennen.

Gleichzeitig steigt der regulatorische Druck. 58 Prozent der Unternehmen berichten laut DataStackHub von verschärften Compliance-Anforderungen an ihre Cloud-Infrastruktur seit 2024. NIS2, DORA, DSGVO — die Vorgaben werden konkreter, und die Bußgelder höher.

Das Problem beginnt fast immer gleich: Ein Team startet ein Pilotprojekt in Azure. Dann kommt das nächste Team. Nach 18 Monaten existieren 40 Subscriptions, verteilt auf drei Abteilungen, mit unterschiedlichen Namenskonventionen und ohne einheitliche Kostenzuordnung.

Unsere Beobachtung aus über 30 Azure-Projekten: Die meisten Governance-Probleme entstehen nicht durch Fahrlässigkeit, sondern weil es am Anfang kein Framework gab. Nachträglich aufräumen kostet das Dreifache.

Management Groups: Die Hierarchie, die alles zusammenhält

Management Groups sind das Fundament jeder Azure Governance. Sie bilden eine Hierarchie oberhalb Ihrer Subscriptions — vergleichbar mit einer Ordnerstruktur, in der Policies, Zugriffsrechte und Budgets automatisch an alle darunterliegenden Ebenen vererbt werden.

Das Cloud Adoption Framework von Microsoft empfiehlt diese Struktur:

Tenant Root Group
├── Platform
│ ├── Identity (Azure AD, Conditional Access)
│ ├── Connectivity (Hub-Netzwerk, Firewall, DNS)
│ └── Management (Monitoring, Logging, Automation)
├── Workloads
│ ├── Production (Produktive Systeme)
│ ├── Staging (Pre-Production)
│ └── Sandbox (Entwicklung, PoCs)
└── Decommissioned (Auslaufende Subscriptions)

Unsere Empfehlung: Starten Sie nicht mit einer flachen Struktur. Selbst bei nur drei Subscriptions lohnt es sich, die Platform/Workloads-Trennung von Beginn an einzuziehen. Die spätere Migration von Subscriptions zwischen Management Groups ist zwar möglich, aber aufwändig — weil Policies und RBAC-Zuweisungen neu evaluiert werden müssen.

Mit Terraform setzen Sie diese Hierarchie in wenigen Minuten auf:

# Management Group Hierarchie — Terraform
resource "azurerm_management_group" "platform" {
  display_name               = "Platform"
  parent_management_group_id = data.azurerm_management_group.tenant_root.id
}

resource "azurerm_management_group" "workloads" {
  display_name               = "Workloads"
  parent_management_group_id = data.azurerm_management_group.tenant_root.id
}

resource "azurerm_management_group" "production" {
  display_name               = "Production"
  parent_management_group_id = azurerm_management_group.workloads.id
}

resource "azurerm_management_group" "sandbox" {
  display_name               = "Sandbox"
  parent_management_group_id = azurerm_management_group.workloads.id
}

# Subscription in Management Group einordnen
resource "azurerm_management_group_subscription_association" "prod_sub" {
  management_group_id = azurerm_management_group.production.id
  subscription_id     = "/subscriptions/${var.prod_subscription_id}"
}

Ein Fehler, den wir häufig sehen: Teams weisen Policies direkt auf der Tenant Root Group zu. Das erschwert das Debugging massiv, weil jede Subscription diese Policies erbt und sich Ausnahmen nur schwer nachvollziehen lassen. Besser: Policies auf der Platform- oder Workloads-Ebene zuweisen.


Azure Policy as Code: Leitplanken statt Kontrollverlust

Azure Policy ist das Werkzeug, mit dem Sie Regeln für Ihre gesamte Azure-Umgebung definieren und durchsetzen. Statt Richtlinien in ein Wiki zu schreiben, das niemand liest, codieren Sie sie direkt in die Infrastruktur.

43 Prozent aller Cloud-Sicherheitsvorfälle gehen auf Konfigurations- oder Compliance-Verstöße zurück. Azure Policy verhindert diese Verstöße automatisch — entweder durch Audit (nur melden) oder Deny (aktiv blockieren).

Hier eine Policy, die sicherstellt, dass alle Ressourcen ein CostCenter-Tag tragen:

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
      "field": "tags['CostCenter']",
      "exists": "false"
    },
    "then": {
      "effect": "deny"
    }
  },
  "parameters": {},
  "displayName": "CostCenter-Tag erzwingen",
  "description": "Blockiert die Erstellung von Ressourcen ohne CostCenter-Tag."
}

Diese Policy weisen Sie per Azure CLI auf Management-Group-Ebene zu:

# Policy auf Workloads-Management-Group zuweisen
az policy assignment create 
  --name "enforce-costcenter-tag" 
  --display-name "CostCenter-Tag erzwingen" 
  --policy "/providers/Microsoft.Authorization/policyDefinitions/<policy-id>" 
  --scope "/providers/Microsoft.Management/managementGroups/workloads" 
  --enforcement-mode Default

Welche Policies Sie ab Tag 1 brauchen:

Policy Effekt Warum
CostCenter-Tag erzwingen Deny Kostenzuordnung ab der ersten Ressource
Erlaubte VM-Größen Deny Verhindert M-Series für Testumgebungen
Verschlüsselung erzwingen Deny DSGVO-Basisschutz
Erlaubte Regionen Deny Daten bleiben in EU (westeurope, northeurope)
Diagnostics-Einstellungen DeployIfNotExists Logging für alle Ressourcen
Public-IP blockieren Deny Kein versehentlich offener Zugang

Unser Rat: Beginnen Sie mit dem Audit-Effekt, um den aktuellen Compliance-Stand zu erheben. Erst wenn das Team die Regeln versteht und die bestehenden Ressourcen konform sind, schalten Sie auf Deny um. Ein harter Deny am ersten Tag blockiert sonst legitime Deployments und frustriert die Entwickler.


Landing Zones: Das Gesamtpaket für den Start

Eine Azure Landing Zone ist kein einzelnes Tool, sondern eine vorkonfigurierte Umgebung, die Management Groups, Policies, Netzwerk und Identity als Gesamtpaket bereitstellt. Microsoft liefert mit dem Cloud Adoption Framework einen Referenz-Blueprint, der sich per Terraform oder Bicep ausrollen lässt.

Für Mittelständler mit 300 bis 3.000 Mitarbeitenden empfehlen wir den „Start Small“-Ansatz:

Phase 1 (Woche 1–2): Management-Group-Hierarchie, Basis-Policies (Tags, Regionen, Verschlüsselung), RBAC-Rollenmodell mit drei Ebenen (Platform Admin, Workload Owner, Developer).

Phase 2 (Woche 3–4): Hub-and-Spoke-Netzwerk mit Azure Firewall, Connectivity-Subscription, Diagnostics und Log Analytics Workspace.

Phase 3 (Monat 2–3): FinOps-Integration mit Azure Cost Management, Budgets und Alerts, Reserved Instance Empfehlungen. Unternehmen, die Reserved Instances und Savings Plans konsequent nutzen, sparen 30 bis 50 Prozent gegenüber Pay-as-you-go.

Phase 4 (laufend): Policy-Drift-Detection über CI/CD-Pipelines, Compliance-Dashboard für die Geschäftsführung, quartalsweise Reviews.

Weniger als 20 Prozent der Unternehmen können heute eine durchgängige Compliance über alle Cloud-Workloads nachweisen. Eine sauber aufgesetzte Landing Zone bringt Sie in diese Gruppe — nicht durch mehr Kontrolle, sondern durch bessere Automatisierung.


FinOps und Governance: Kosten gehören ins Framework

Kostenmanagement ist kein separates Thema — es gehört in die Governance-Struktur. Seit 2025 gilt es als Best Practice, FinOps direkt in das Governance-Framework zu integrieren, statt es als Nachgedanken zu behandeln.

Drei Hebel, die sofort wirken:

  1. Tag-basierte Kostenzuordnung: Die CostCenter-Policy von oben ist der erste Schritt. Ergänzen Sie Tags für Environment, Team und Project. Damit lassen sich Kosten in Azure Cost Management granular nach Abteilungen und Projekten aufschlüsseln.
  1. Budgets mit Alerts: Setzen Sie Budgets pro Subscription oder Resource Group. Azure Cost Management benachrichtigt bei 80 und 100 Prozent Auslastung. Das verhindert Kostenexplosionen durch vergessene Ressourcen.
  1. Rightsizing-Automatisierung: Azure Advisor liefert konkrete Empfehlungen für überdimensionierte VMs. Allein das Löschen ungenutzter Ressourcen und Rightsizing spart in den ersten Wochen 15 bis 25 Prozent.

48 Prozent der FinOps-Teams setzen bereits auf KI-gestützte Anomalie-Erkennung. Für den Mittelstand reicht zunächst die native Azure Cost Management Integration — aber die muss aktiv konfiguriert und in die Governance eingebettet werden.


Häufige Fehler — und wie Sie sie vermeiden

In unseren Azure-Consulting-Projekten sehen wir wiederkehrende Muster:

Fehler 1: Governance wird aufgeschoben. „Wir machen das, wenn wir größer sind.“ Das stimmt nie. Die Kosten für nachträgliches Aufräumen übersteigen die Initialinvestition um den Faktor drei bis fünf.

Fehler 2: Zu viele Policies auf einmal. 200 Policies am ersten Tag führen zu Frustration. Starten Sie mit sechs bis acht Kern-Policies und erweitern Sie quartalsweise.

Fehler 3: Kein Policy-as-Code-Workflow. Policies, die manuell über das Portal erstellt werden, driften. Versionieren Sie Ihre Policies in Git und deployen Sie sie über CI/CD — genau wie Ihre Anwendungen.

Fehler 4: RBAC zu granular. 40 Custom Roles mit feingranularen Berechtigungen sind nicht wartbar. Nutzen Sie die Built-in Roles von Azure und ergänzen Sie nur dort Custom Roles, wo es zwingend nötig ist.

Wenn Sie unsicher sind, wo Ihre Azure-Umgebung steht, kann ein AI Readiness Assessment oder ein gezielter Workshop den Status quo in zwei Tagen transparent machen.


Nächste Schritte: Governance aufsetzen oder verbessern

Azure Governance ist kein Einmalprojekt. Es ist ein operatives Framework, das mit Ihrem Unternehmen wächst. Der wichtigste Schritt ist der erste: Management Groups aufsetzen, sechs Basis-Policies aktivieren und ein RBAC-Modell definieren.

Wer das intern nicht stemmen kann oder Bestandsumgebungen bereinigen muss, braucht einen Partner, der die Governance-Patterns kennt — und sie an die Realität des Mittelstands anpasst. Als Microsoft Solutions Partner mit 80 Mitarbeitenden und Erfahrung aus über 30 Azure-Projekten ist das genau unser Feld.

[Kostenloses Erstgespräch vereinbaren — Azure Governance Review in 2 Wochen.](/kontakt/)

Wir analysieren Ihre bestehende Azure-Umgebung, identifizieren Governance-Lücken und liefern einen konkreten Umsetzungsplan. Schauen Sie sich dazu auch unsere Referenzprojekte und unseren Ansatz zu Platform Engineering an.


FAQ

Was kostet Azure Governance?

Die Azure-Dienste selbst (Management Groups, Azure Policy, RBAC) sind kostenlos. Kosten entstehen für Log Analytics Workspace (abhängig vom Datenvolumen) und gegebenenfalls für externe Beratung beim Erstaufbau. Für ein Unternehmen mit fünf bis zehn Subscriptions rechnen Sie mit zwei bis vier Wochen für das Erstsetup.

Können wir Governance nachträglich einführen?

Ja, aber es ist aufwändiger. Bestehende Ressourcen müssen auf Compliance geprüft und gegebenenfalls migriert werden. Die Management-Group-Hierarchie lässt sich jederzeit aufbauen, aber Subscription-Umzüge erfordern sorgfältige Planung wegen RBAC- und Policy-Vererbung.

Brauchen wir eine Landing Zone, wenn wir nur drei Subscriptions haben?

Gerade dann. Die Landing Zone ist bei drei Subscriptions in einer Woche aufgesetzt und verhindert, dass Sie bei zehn Subscriptions von vorne anfangen müssen. Der Aufwand skaliert überproportional mit der Anzahl ungeordneter Subscriptions.

Azure Policy Deny oder Audit — was ist besser?

Starten Sie mit Audit, um den Ist-Zustand zu erfassen. Sobald bestehende Ressourcen konform sind und das Team die Regeln kennt, schalten Sie auf Deny um. Ein sofortiges Deny blockiert sonst legitime Deployments und erzeugt Widerstand im Team.

Wie unterscheidet sich Azure Governance von Azure Security Center?

Azure Governance (Management Groups, Policy, RBAC) definiert die Regeln und Struktur. Microsoft Defender for Cloud (ehemals Security Center) überwacht die Sicherheitslage und gibt Empfehlungen. Beides ergänzt sich: Governance setzt die Leitplanken, Defender prüft, ob sie eingehalten werden.