Wer sich mit Azure Governance beschäftigt, stößt fast zwangsläufig auf die Landing Zones des Microsoft Cloud Adoption Framework (CAF). Spätestens im AZ-104 oder AZ-305 tauchen Begriffe wie Platform, Identity, Connectivity, Corp, Online und Sandbox auf. Viele Administratoren ziehen daraus einen Schluss, der so nicht stimmt: „Wenn Microsoft das empfiehlt, muss meine Umgebung genauso aussehen.“ Das Gegenteil ist richtig. Eine Landing Zone ist kein Architekturdiagramm zum Nachbauen. Sie ist das Ergebnis von Entscheidungen und diese Entscheidungen fallen für ein DAX-Unternehmen anders aus als für ein kleines Unternehmen oder einen Managed Service Provider.
Die Enterprise-Scale-Referenzarchitektur zeigt eine tiefe Hierarchie: Tenant Root, darunter Platform mit den Bereichen Identity, Management und Connectivity, daneben Landing Zones mit Corp und Online, dazu Sandbox und Decommissioned. Folgende Abbildung zeigt die CAF-Empfehlung von Microsoft.
Das Missverständnis: Enterprise-Scale als Standardlösung
Für ein Unternehmen mit tausenden Nutzern, mehreren Plattformteams und einer eigenen Netzwerkabteilung ergibt diese Tiefe Sinn. Für ein kleines Unternehmen meist nicht. Genau Setzt der typische Denkansatz eines echten Azure-Cloud-Architekten an: Nicht die Referenzarchitektur kopieren, sondern prüfen, welcher Teil davon zum eigenen Betrieb passt.
Ein Praxisbeispiel: das kleine IT-Schulungsunternehmen
Nehmen wir ein kleines Unternehmen, das IT-Schulungen anbietet, wie Meines. Im Dauerbetrieb laufen Azure Virtual Desktop, FSLogix-Dateifreigaben, ein Active-Directory-Lab und Microsoft Sentinel. Dazu kommen regelmäßig temporäre Kursumgebungen, die nach der Schulung wieder gelöscht werden. Ein erster Entwurf orientierte sich eng am Cloud Adoption Framework, d. h : eigene Management Groups für Identity, Connectivity, Platform und Sandbox. Auf den ersten Blick sauber, aber bei genauerem Hinsehen zeigt sich ein Problem.
Die entscheidende Frage: Läuft das dauerhaft?
Eine typische Connectivity-Management-Group enthält Azure Firewall, Hub-Netzwerke, VPN-Gateways, ExpressRoute und Bastion Hosts. Die Frage lautet nicht „gehört das zu Connectivity?“, sondern: Wird diese Komponente dauerhaft betrieben?
In unserem Beispiel lautet die Antwort Nein. Firewall, Bastion und Hub-Spoke-Netzwerke entstehen nur für Schulungen und verschwinden danach wieder. Eine eigene Connectivity-Management-Group erübrigt sich damit vollständig. Diese eine Frage – dauerhaft oder temporär? – entscheidet in der Praxis mehr über die Struktur einer Landing Zone als jedes Referenzdiagramm.
Workload-Sicht statt Plattform-Sicht
Ein zweites Beispiel zeigt denselben Mechanismus aus einer anderen Richtung: Wo gehört der Storage Account für FSLogix hin? Der erste Reflex sagt: Storage ist Infrastruktur, also Plattform. Bei genauer Betrachtung stimmt das nicht. Der Storage Account bedient ausschließlich Azure Virtual Desktop. Er gehört zum Workload, nicht zur Plattform. Diese Unterscheidung wirkt kleinlich, ist es aber nicht: Sie entscheidet, wer die Ressource verwaltet, welche Policies greifen und wie die Kosten zugeordnet werden.
Die tatsächliche Struktur
Aus diesen beiden Prinzipien – dauerhaft versus temporär, Plattform versus Workload – entsteht In unseren hypothetischen Beispielen eine deutlich einfachere Hierarchie:
| Management Group | Inhalt |
|---|---|
| Platform | Zentrale, dauerhaft genutzte Dienste: Sentinel, Log Analytics, Defender for Cloud |
| Shared Services | AVD-Session-Hosts, FSLogix, Domain Controller, Member Server, Test-Clients |
| Training Labs | Temporäre Kursumgebungen, kein festes Netzwerkdesign, pro Kurs neu aufgebaut |
| Sandbox | Preview-Features, Proof-of-Concepts, Experimente ohne Auswirkung auf den Produktivbetrieb |
Wir arbeiten also hier mit 4 Ebenen statt 7, also keine Connectivity-Management-Group, keine separate Identity-Ebene, kein Corp/Online-Split. Für Training Labs gilt zusätzlich eine bewusste Nicht-Entscheidung: Die Landing Zone legt keine Netzwerkarchitektur für Lab-Umgebungen fest. Ein Kurs braucht vielleicht Hub-and-Spoke, der nächste nur ein einzelnes VNet, der dritte Private Endpoints. Jedes Lab bekommt, was der Kurs tatsächlich benötigt – nicht, was ein generisches Template vorschreibt.
Der eigentliche Kern: Governance statt Infrastruktur
Die vielleicht wichtigste Erkenntnis aus diesem Beispiel: Eine gute Landing Zone (Zumindest für dieses Beispiel), besteht kaum aus Infrastruktur-Elementen, sondern im Wesentlichen aus Governance-Entitäten wie Management Groups, Azure Policies und Resource-Tags. Konkret heißt das:
- Allowed Locations (Deny): Ressourcen nur in ausgewählten Regionen, etwa Germany West Central, Germany North, West Europe und einige weitere – so bleiben AI-, AVD- und Compliance-Szenarien möglich, ohne die Region offen zu lassen.
- Allowed VM Sizes (Deny): Kosteneffiziente Familien wie die B-Serie oder Dsv5/Dasv5/Dpsv5 mit maximal vier vCPUs.
- Required Tags (Audit): Owner, Purpose und Environment, zunächst im Audit-Modus statt hart erzwungen.
- Budget: Ein Kostenbudget je Resource Group mit Benachrichtigungen bei 50, 75 und 100 Prozent – frühzeitige Warnung statt Überraschung auf der Rechnung.
Diese vier Bausteine – Locations, VM-Größen, Tags, Budget – leisten mehr für eine funktionierende Umgebung als jede zusätzliche Management-Group-Ebene. Sie kosten nichts an Betrieb, verhindern Fehlkonfigurationen frühzeitig und lassen sich mit wenigen Policy-Zuweisungen umsetzen.
Fazit: Landing Zones bestehen aus Entscheidungen
Das Cloud Adoption Framework liefert hervorragende Referenzarchitekturen. Die eigentliche Arbeit besteht darin, für den eigenen Betrieb zu prüfen, welcher Teil davon wirklich gebraucht wird und welcher nur zusätzliche Komplexität erzeugt. Für kleine und mittlere Unternehmen gilt dabei häufig ein einfacher Grundsatz: weniger Architektur, mehr Governance.
Zwei Fragen reichen oft aus, um eine Enterprise-Scale-Vorlage auf das richtige Maß zu bringen: Läuft diese Komponente dauerhaft? Und: Gehört sie zur Plattform oder zum Workload? Wer diese beiden Fragen konsequent stellt, baut keine kleinere Kopie der Microsoft-Referenzarchitektur – sondern eine Landing Zone, die zum eigenen Unternehmen passt.
💡 Tipp: Sie wollen Management Groups, Policies und Budgets nicht nur verstehen, sondern selbst konzipieren und deployen? → Zum Kursangebot