Azure Landing Zone Diagramm: Management Groups, Subscriptions und Hub-Netzwerk

Die meisten Azure-Umgebungen beginnen gleich. Jemand legt eine Subscription für einen Pilot an, dann eine für Produktion, dann bekommt jedes Team eine eigene. Zwei Jahre später hängen 40 Subscriptions unter der Tenant Root Group, drei betreiben eigene VPN-Gateways, eine Datenbank-VM hat eine öffentliche IP, und niemand weiß, welche Policies wo gelten.

Eine Azure Landing Zone ist Microsofts Blaupause, um genau das zu vermeiden. Dieser Beitrag behandelt jeden Teil mit einem Diagramm: Management Groups, Platform- gegenüber Workload-Landing-Zones, Policy-Guardrails, Hub-and-Spoke gegenüber Virtual WAN, Identität und Deployment.

Was eine Azure Landing Zone ist

Das Cloud Adoption Framework (CAF) definiert eine Azure Landing Zone als „eine bewährte und flexible Architektur, um eine Azure-Umgebung mit mehreren Subscriptions zu steuern, abzusichern und zu skalieren“ (Microsoft Learn). Sie besteht aus zwei Teilen:

• Die Platform Landing Zone: die Management-Group-Hierarchie plus gemeinsame Ressourcen wie Hub-Netzwerk, Logging und Security-Tooling. Microsoft empfiehlt eine pro Microsoft-Entra-Tenant, betrieben von einem Platform-Team.
• Workload-Landing-Zones: eine pro Workload, im Besitz des jeweiligen Teams, mit allen Umgebungen (Entwicklung, Test, Produktion) als eine oder mehrere Subscriptions. Ältere Unterlagen nennen sie Application Landing Zones.

Die Subscription ist der Baustein: CAF nennt sie eine Einheit für Verwaltung, Abrechnung und Skalierung. In AWS-Begriffen entspricht eine Subscription ungefähr einem Account und eine Management Group einer Organizational Unit; das AWS-Landing-Zone-Diagramm zeigt diese Seite.

Die Management-Group-Hierarchie

Eine Policy- oder Rollenzuweisung auf einer Management Group gilt für alles darunter, und Subscription-Owner können sie nicht ändern. Laut Dokumentation zu Management Groups erlaubt Azure 10.000 Management Groups pro Tenant, sechs Ebenen unterhalb der Root und jeweils einen Parent.

Die Referenzhierarchie, mit Hinweisen zu den Standard-ALZ-Policy-Zuweisungen:

Drei Regeln aus dem CAF-Leitfaden zu Management Groups ersparen die meisten Neuentwürfe:

1. Halte es flach. Drei oder vier Ebenen reichen; lege keine Management Groups für Regionen oder für Entwicklung, Test und Produktion an.
2. Weise am Intermediate Root zu, nicht an der Tenant Root. Neue Subscriptions landen standardmäßig unter der Tenant Root, und jeder Benutzer kann Management Groups anlegen, bis du dafür eine Berechtigung verlangst. Ändere beides und mache Sandbox zum Standard.
3. Gib Workload-Teams Rollen auf Subscription-Ebene. Platform-Teams dürfen Rollen auf Management Groups halten, gesteuert mit Just-in-Time-Zugriff.

Die Namen ändern sich: Security kam 2025 zu Platform, und die neueste CAF-Übersicht nutzt „Workload landing zones“ für Landing zones und „Internal“ für Corp.

Platform- gegenüber Workload-Landing-Zones

Beim Subscription Vending legt eine Anfrage, oft ein Pull Request, die Subscription unter Corp oder Online an, weist Rollen und ein Budget zu und fügt für Corp einen Spoke hinzu, der mit dem Hub gepeert ist. Microsoft veröffentlicht Vending-Module für Bicep und Terraform.

Policy-gesteuerte Guardrails

Azure Policy macht aus der Hierarchie Durchsetzung: Weise eine Regel einmal an einer Management Group zu, und jede aktuelle und künftige Subscription darunter erbt sie.

Regionsregeln brauchen Sorgfalt: Die integrierte Policy „Allowed locations“ überspringt Ressourcengruppen und den Standort global. Kombiniere sie deshalb mit „Allowed locations for resource groups“ und starte im Modus DoNotEnforce, um zu sehen, was sie blockieren würde:

az policy assignment create \
  --name allowed-locations \
  --scope /providers/Microsoft.Management/managementGroups/contoso \
  --policy e56962a6-4747-49cd-b67b-bf8b01975c4c \
  --params '{"listOfAllowedLocations": {"value": ["westeurope", "northeurope"]}}' \
  --enforcement-mode DoNotEnforce

Das Timing zählt: Eine neue Zuweisung greift nach etwa fünf Minuten, eine in eine Management Group verschobene Subscription wird nach etwa 30 Minuten ausgewertet, und alle 24 Stunden läuft ein vollständiger Scan. DeployIfNotExists- und Modify-Policies wirken auf neue und aktualisierte Ressourcen; bestehende brauchen einen Remediation-Task.

Netzwerk: Hub-and-Spoke oder Virtual WAN

Die Connectivity-Subscription besitzt das gemeinsame Netzwerk: Azure Firewall, VPN- und ExpressRoute-Gateways, Bastion, Private-DNS-Zonen und den DNS Private Resolver. Der Leitfaden zur Netzwerktopologie von CAF bietet zwei Designs:

Peering ist nicht transitiv. In einem Hub Virtual Network bekommt deshalb jeder Spoke eine Routing-Tabelle, die 0.0.0.0/0 an die private IP der Firewall schickt, das Hub-Peering erlaubt Gateway Transit, und das Spoke-Peering nutzt das Remote-Gateway; der Beitrag zur Hub-and-Spoke-Netzwerktopologie behandelt das Routing. Azure Firewall Basic schafft bis zu 250 Mbps, Standard 30 Gbps und Premium 100 Gbps. Wähle für Virtual WAN den Typ Standard; Basic unterstützt nur Site-to-Site-VPN.

Bei DNS machen Teams am häufigsten Fehler. Private-DNS-Zonen wie privatelink.blob.core.windows.net liegen in der Connectivity-Subscription und sind mit dem Hub verknüpft, wo der DNS Private Resolver an Azure DNS unter 168.63.129.16 weiterleitet; lokale DNS-Server leiten Zonen wie blob.core.windows.net an ihn weiter. Eine DeployIfNotExists-Policy in Corp schreibt den Eintrag jedes Private Endpoints in die zentrale Zone, sodass Workload-Teams dafür keine Rechte brauchen.

Identität

Der Microsoft-Entra-Tenant ist die Identitätsgrenze. Die praktischen Regeln von CAF:

• Gib Workload-Teams beim Vending Rollen auf ihren eigenen Subscriptions, nie auf Management Groups.
• Lass Platform-Engineers Rollen wie Owner über Privileged Identity Management (PIM) aktivieren, mit Genehmigung und Zeitlimit.
• Wende Conditional Access auf alle an, die Azure verwalten, und halte überwachte Notfallzugriffskonten bereit.
• Nutze die Identity-Subscription für Domain Controller oder Microsoft Entra Domain Services, falls Workloads sie noch brauchen.

Deployment

Zum Zeitpunkt des Schreibens (November 2026) empfiehlt Microsoft den Azure Landing Zones IaC Accelerator: Bicep oder Terraform auf Basis von Azure Verified Modules (AVM). Sein PowerShell-Modul richtet ein GitHub- oder Azure-DevOps-Repository ein, Pipelines mit Genehmigungen und Managed Identities mit Federated Credentials. Terraform nutzt getrennte Module für Hierarchie und Policy (avm-ptn-alz), Management-Ressourcen und jedes Netzwerkdesign; Bicep nutzt Deployment Stacks, die Ressourcen löschen können, die du aus den Templates entfernst.

Ältere Optionen laufen aus: Das Terraform-Modul caf-enterprise-scale ist veraltet, und das klassische ALZ-Bicep verließ den Accelerator am 16. Februar 2026; sein Repository wird am 16. Februar 2027 archiviert. Ein Portal-Accelerator bleibt bestehen, ist aber ohne Code schwer zu aktualisieren.

Plane das Budget ein. Die Szenarioseite des Accelerators schätzt die feste Infrastruktur auf etwa 5.640 USD im Monat für ein Single-Region-Hub-and-Spoke mit Azure Firewall und 690 USD für die Variante für kleine Unternehmen, die unter anderem den DDoS-Network-Protection-Plan abschaltet (Retail-Preise für westus von April 2026, ohne Traffic und Logs). Dazu brauchst du vier Platform-Subscriptions, oder zwei im Setup für kleine Unternehmen.

Das Azure-Landing-Zone-Diagramm

So liest du es:

• Der Baum links ist die Hierarchie; Pfeile zeigen vom Parent zum Child, in Richtung der Vererbung.
• Der Policy-Node hängt am Contoso-Intermediate-Root, nicht an der Tenant Root Group, und erreicht so die gesamte Landing Zone und nichts sonst.
• Farben zeigen den Besitz: Blau für Platform, Grün für Workloads, Bernstein für Sandbox, Grau für die Root und stillgelegte Subscriptions.
• Gestrichelte Kanten zeigen die Platzierung: Der Hub liegt in der Connectivity-Subscription, und beide Spokes werden in Corp bereitgestellt.
• Durchgezogene Kanten führen Traffic: Peering zum Hub und die Gateway-Verbindung zu On-Premises; jeder Spoke routet 0.0.0.0/0 an die Firewall unter 10.0.0.4.
• Der Markdown-Block listet die wichtigsten Limits.

Azure-Landing-Zone-Diagramme klar zeichnen

• Zeichne Governance und Netzwerk als zwei Ansichten, verbunden nur dort, wo eine Subscription liegt.
• Hänge jede Policy dort an, wo sie zugewiesen ist, damit Leser sehen, welche Workloads sie einschränkt.
• Zeige ein oder zwei Beispiel-Subscriptions pro Gruppe, kein Inventar.
• Schreibe Adressbereiche an den Hub und jeden Spoke; Überschneidungen prüfen Reviewer zuerst.
• Vermeide die klassischen Fehler: Peering als transitiv gezeichnet, Workloads unter der Tenant Root sowie Regionen oder Umgebungen als Management Groups.

Siehe Cloud-Architekturdiagramme für typisierte Cloud-Nodes und den Beitrag zum Terraform-Architekturdiagramm für Umgebungen, die mit Terraform verwaltet werden.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und lege ein Diagramm an.
2. Füge acht Cloud-Ressource-Nodes aus dem Pack Cloud hinzu: Tenant root group, Contoso, Platform, Landing zones, Corp, Online, Sandbox und Decommissioned. Schreibe jede Rolle in die Zeile für den Ressourcentyp und ordne sie als eingerückten Baum an.
3. Verbinde Parents mit Children über orthogonale Kanten und färbe die Zweige: Blau für Platform, Grün für Landing zones, Bernstein für Sandbox.
4. Füge einen Richtlinie-Node aus dem Pack Sicherheit namens Azure Policy guardrails hinzu und verbinde ihn mit Contoso.
5. Füge einen VPC-Node aus dem Pack Netzwerk für den Hub hinzu, mit einem Router für das Gateway und einer Firewall darin, sowie zwei VPC-Nodes für die Spokes, jeweils mit einer Text-Zeile aus dem Pack Basis für ihre Route.
6. Zeichne gestrichelte Kanten von Platform zum Hub und von Corp zu den Spokes, Peering-Kanten zum Hub und eine Kante vom Gateway zu einem Text-Label für On-Premises.
7. Füge einen Markdown-Block aus dem Pack Basis mit den Limits hinzu.

Wenn deine Landing Zone in Terraform liegt, macht das Tool Terraform to diagram aus den Dateien einen ersten Entwurf.

Das Beispiel nutzt 15 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist eine Azure Landing Zone? Eine Azure-Umgebung mit mehreren Subscriptions, die vor dem Eintreffen der Workloads nach den Empfehlungen des Cloud Adoption Framework aufgebaut wird: Management Groups, Policy-Guardrails, Identität, Logging und ein gemeinsames Netzwerk.

Welche Management Groups nutzt eine Azure Landing Zone? Einen Intermediate Root unter der Tenant Root Group, darunter Platform (Management, Connectivity, Identity, Security), Landing zones (Corp, Online, Local), Sandbox und Decommissioned.

Was ist der Unterschied zwischen Corp- und Online-Landing-Zones? Corp enthält Workloads, die das Firmennetzwerk über den Hub erreichen; deshalb verbieten die Standardwerte dort öffentliche PaaS-Endpunkte und öffentliche IPs an Netzwerkschnittstellen. Online enthält Workloads, die direkten Internetzugang oder kein virtuelles Netzwerk brauchen.

Sollte ich Hub-and-Spoke oder Virtual WAN nutzen? Ein Hub Virtual Network passt zu wenigen Regionen, weniger als 30 Site-to-Site-Tunneln und voller Routing-Kontrolle; Virtual WAN passt zu vielen Regionen und Niederlassungen, SD-WAN oder VPN-zu-ExpressRoute-Transit.

Wird das Terraform-Modul caf-enterprise-scale noch unterstützt? Nein. Es ist veraltet und erhält keine Updates. Nutze die Azure Verified Modules für die Platform Landing Zone, meist über den IaC-Accelerator; Microsoft dokumentiert einen Migrationspfad.

Kostenlos starten — ein Seat, keine Kreditkarte.