Eine schlanke Governance genügt für die Azure Landing Zone im Mittelstand

Wer den Begriff Azure Landing Zone schon einmal im Microsoft-Umfeld gehört und sich anschließend durch die offiziellen Unterlagen gearbeitet hat, weiß, wie schnell das Thema ausufert. Gerade in kleinen und mittleren Unternehmen erlebe ich oft Unsicherheit darüber, wie viel man davon wirklich braucht und wie man ohne monatelanges Projekt zu einer brauchbaren Governance kommt. In vielen Tenants, die ich mir ansehe, fehlt eine klare Struktur, oder man arbeitet so lange mit Bordmitteln weiter, bis niemand mehr den Überblick hat. Dabei genügen schon wenige, gut überlegte Schritte für eine solide Grundlage, ohne das gesamte Cloud Adoption Framework bis ins letzte Detail umzusetzen.

Eine schlanke Management-Group-Hierarchie trennt Plattform und Workloads

Am Anfang steht fast immer eine Management-Group-Hierarchie. Kleineren Unternehmen genügt meist eine überschaubare Struktur mit vier Bereichen: „Platform“ für zentrale Dienste wie Netzwerke und Identität, „Landing Zones“ (häufig nach Geschäftsbereich oder Umgebung unterteilt, etwa in „Corp“ und „Online“), eine „Sandbox“ für Experimente und schließlich „Decommissioned“ als Ablage für ausgemusterte Subscriptions, die noch aufbewahrt werden. Das sieht dann etwa so aus:

flowchart TD
    root["Root"]
    platform["Platform"]
    landingzones["Landing Zones"]
    corp["Corp"]
    online["Online"]
    sandbox["Sandbox"]
    decomm["Decommissioned"]

    root --> platform
    root --> landingzones
    root --> sandbox
    root --> decomm
    landingzones --> corp
    landingzones --> online

Abbildung: Beispiel für eine Management-Group-Hierarchie in einer Azure Landing Zone.

In dieser Hierarchie lassen sich Subscriptions logisch gruppieren und getrennt verwalten. Besonders die Trennung zwischen der Plattform und den workloadspezifischen Landing Zones hat sich in der Praxis bewährt. Wer schnell einsteigen und mehr über den Ansatz erfahren möchte, findet die Details in Microsofts Übersicht zu Management Groups.

Schon zwei Subscriptions schaffen eine saubere Trennung

Oft bekomme ich zu hören: „Wir brauchen doch nur eine Subscription?“ Für den Anfang mag das stimmen. Trotzdem rate ich dazu, früh mindestens zwei Subscriptions einzuplanen, eine für Plattformressourcen und eine für produktive Workloads. Spätestens wenn Sandbox-Umgebungen dazukommen oder Datenhaltung und Abrechnung sauber getrennt sein sollen, macht sich das bezahlt. In Azure sind Subscriptions die kleinste Verwaltungseinheit, für die Abrechnung ebenso wie für Quotas oder um einzelne Bereiche im Ernstfall isolieren zu können. Wer später wachsen will, hat mit dieser Trennung einen großen Vorteil.

Wenige Azure Policies auf Management-Group-Ebene verhindern viel Wildwuchs

In der Azure-Governance werden Richtlinien häufig unterschätzt. Dabei lässt sich schon mit wenigen Policies auf Management-Group-Ebene eine Menge Wildwuchs vermeiden. Zum Start empfehle ich meist diese Klassiker:

• Nur erlaubte Regionen zulassen
• Bestimmte Tags (z. B. „Owner“ oder „CostCenter“) erzwingen
• Öffentlich erreichbare IPs an kritischen Stellen verhindern
• Überwachungseinstellungen (Diagnostics) zumindest prüfen, oft auditieren

In der Regel decken die integrierten Azure Policies das bereits ab, eigene Richtlinien lassen sich später nach und nach ergänzen. Weil Zuweisungen auf Management-Group-Ebene flexibel nach unten vererbt werden, bleibt der Aufwand gering. Einen guten Überblick für den tieferen Einstieg gibt die Dokumentation zu Azure Policy.

Hier ein einfaches Beispiel für eine Policy-Zuweisung, die nur bestimmte Standorte erlaubt:

{
  "if": {
    "not": {
      "field": "location",
      "in": ["westeurope", "northeurope"]
    }
  },
  "then": {
    "effect": "deny"
  }
}

Gruppenbasiertes RBAC und Defender for Cloud bilden die Sicherheitsbasis

Berechtigungen (RBAC) sollten von Anfang an über Gruppen vergeben werden, am besten über Entra-ID-Gruppen, und für erhöhte Rollen wie Owner oder Contributor möglichst über Privileged Identity Management (PIM). Wer Einzelpersonen direkt auf Subscriptions berechtigt, bereut das spätestens beim ersten Mitarbeiterwechsel. Bei der Sicherheit beginne ich immer früh mit einer Basiskonfiguration von Defender for Cloud. Mir geht es dabei nicht darum, jede erweiterte Funktion einzuschalten, sondern um eine Grundüberwachung, die die wichtigsten Schwachstellen abdeckt. Wer außerdem die Kosten im Blick behalten möchte, kann im Beitrag Azure-Kosten im Griff – Budgets, Tags, Advisor nachlesen, wie sich Governance und Kostentransparenz sinnvoll ergänzen.

Mein Tipp: Auch in kleinen Teams lohnt es sich, die ersten Rollen- und Policy-Zuweisungen nachvollziehbar festzuhalten. Spätestens wenn ein neuer Kollege eingearbeitet wird oder jemand eine Ressourcengruppe übernimmt, erspart das viel Ärger.

Eine einfache Namenskonvention hilft mehr als das komplette Framework

Namenskonventionen klingen nach trockener Pflichtübung, sind für Übersicht und Automatisierung aber unverzichtbar. Ich arbeite gern mit einer einfachen Struktur wie „[Org]-[Umgebung]-[Ressourcentyp]-[Laufnummer]“, also etwa „contoso-prd-vm-001“. Eine überschaubare Regel, an die sich alle halten, bringt mehr als ein 10-seitiges Namenshandbuch, das niemand liest. Das vollständige Landing-Zone-Modell des Cloud Adoption Framework ist mit all seinen Empfehlungen für viele KMU schlicht zu viel auf einmal, deshalb setze ich auf pragmatische Grundlagen. Entscheidend ist, dass die gewählte Struktur mit dem Unternehmen mitwachsen kann.

Ein solider Start braucht keine überfrachtete Architektur

Nach vielen Projekten bin ich überzeugt, dass sich selbst Steine in den Weg legt, wer am Anfang zu kompliziert baut. Eine Azure-Landing-Zone-Governance muss skalieren können, darf aber gerade in kleinen und mittleren Unternehmen nicht überfrachtet sein. Als Fundament reichen oft eine klare Management-Group-Struktur, wenige gezielt gewählte Policies, sauberes RBAC und eine Sicherheitsbasis mit Defender for Cloud. Alles Weitere darf mit den Anforderungen wachsen, sollte aber vom ersten Tag an dokumentiert und nachvollziehbar umgesetzt werden. Das erleichtert die Fehlersuche und legt den Grundstein für spätere Automatisierung und Compliance.