Azure Landing Zones
Fehlstart vermeiden
Veröffentlicht in Ausgabe 11/2025 - PRAXIS
Die Cloud gilt als Synonym für Agilität, Skalierbarkeit und Effizienz. In der Realität zeigt sich jedoch häufig ein anderes Bild: Nach der ersten Migrationswelle kämpfen viele Unternehmen mit einer unübersichtlichen Landschaft aus Subscriptions, inkonsistenter Governance und sicherheitskritischen Lücken. Workloads entstehen ad hoc per ClickOps, zentrale Plattformdienste fehlen oder wurden später mühsam ergänzt. Die technische Grundlage ist selten das Problem – es fehlt an einer strategischen, strukturierten Herangehensweise, die Geschwindigkeit und Kontrolle in Einklang bringt.
Während klassische IT-Architekturen auf planvoller Struktur beruhen, verleitet die Flexibilität der Cloud dazu, mit dem Dach zu beginnen, bevor das Fundament gelegt ist. Doch wer skalieren, automatisieren und sicher betreiben will, braucht genau dieses Fundament – in unserem Fall bereitgestellt durch Azure Landing Zones. Sie definieren eine standardisierte, vorkonfigurierte Umgebung, die zentrale Sicherheits-, Netzwerk- und Identitätsdienste umfasst, Richtlinien durchsetzt und Teams einen gemeinsamen Rahmen für Innovation bietet.
Der Artikel zeigt, wie Azure Landing Zones (ALZ) helfen, fragmentierte Cloudlandschaften in kontrollierbare, sichere und skalierbare Plattformen zu überführen. Im Fokus steht ein plattformorientierter Ansatz, der Governance, Struktur und Wiederverwendbarkeit von Anfang an systematisch verankert, und zwar unabhängig davon, ob bestehende Workloads migriert oder neue Applikationen entwickelt werden.
Die Cloud gilt als Synonym für Agilität, Skalierbarkeit und Effizienz. In der Realität zeigt sich jedoch häufig ein anderes Bild: Nach der ersten Migrationswelle kämpfen viele Unternehmen mit einer unübersichtlichen Landschaft aus Subscriptions, inkonsistenter Governance und sicherheitskritischen Lücken. Workloads entstehen ad hoc per ClickOps, zentrale Plattformdienste fehlen oder wurden später mühsam ergänzt. Die technische Grundlage ist selten das Problem – es fehlt an einer strategischen, strukturierten Herangehensweise, die Geschwindigkeit und Kontrolle in Einklang bringt.
Während klassische IT-Architekturen auf planvoller Struktur beruhen, verleitet die Flexibilität der Cloud dazu, mit dem Dach zu beginnen, bevor das Fundament gelegt ist. Doch wer skalieren, automatisieren und sicher betreiben will, braucht genau dieses Fundament – in unserem Fall bereitgestellt durch Azure Landing Zones. Sie definieren eine standardisierte, vorkonfigurierte Umgebung, die zentrale Sicherheits-, Netzwerk- und Identitätsdienste umfasst, Richtlinien durchsetzt und Teams einen gemeinsamen Rahmen für Innovation bietet.
Der Artikel zeigt, wie Azure Landing Zones (ALZ) helfen, fragmentierte Cloudlandschaften in kontrollierbare, sichere und skalierbare Plattformen zu überführen. Im Fokus steht ein plattformorientierter Ansatz, der Governance, Struktur und Wiederverwendbarkeit von Anfang an systematisch verankert, und zwar unabhängig davon, ob bestehende Workloads migriert oder neue Applikationen entwickelt werden.
Die vorgestellte Architektur dient als universelle Grundlage für alle Workload-Typen – von klassischen Line-of-Business-Anwendungen bis hin zu cloudnativen Services. Es geht nicht um die Auswahl einzelner Azure-Dienste, sondern um das übergeordnete Betriebsmodell. Wer Cloudmigration ernst nimmt, nutzt die Plattform gezielt, statt lediglich virtuelle Maschinen zu verschieben. Erfolgreiche Cloudstrukturen beginnen mit der richtigen Architektur, nicht mit reinem Lift-and-Shift.
Unsichtbare Hürden der Cloudmigration
Die ersten Monate in der Cloud wirken oft vielversprechend: Ressourcen lassen sich schnell bereitstellen, Projekte starten zügig und die bisherigen Grenzen der On-Premises-Welt scheinen überwunden. Doch nach den ersten Workloads kippt die Dynamik. Administratoren stehen zunehmend vor einer unübersichtlichen Umgebung: Subscriptions ohne klare Verantwortlichkeiten, uneinheitliches Tagging, individuelle Netzwerk- und Sicherheitskonfigurationen je Workload. Standardisiertes Logging fehlt häufig und Kosten laufen aus dem Ruder, weil Transparenz über die genutzten Ressourcen fehlt.
Was hier abgeht, ist kein weiteres Tool, sondern ein übergreifendes Betriebsmodell – mit klarer Governance, Struktur und Rollenverteilung. Doch genau das wird im Eifer des Projekterfolgs häufig übersehen. Governance und Plattformarchitektur nachträglich zu implementieren, ist aufwendig und teuer. Der eigentliche Engpass ist selten technischer Natur, sondern liegt in der fehlenden Plattformstrategie. Ohne ein zentrales Modell wird jeder neue Work-load zur individuellen Entscheidung – und jeder Fehler skaliert mit. Dabei wäre der Weg klar: Mit einem fundierten Plattformansatz lassen sich sämtliche Workloads, vom einfachen Webdienst bis zur geschäftskritischen Anwendung, kontrolliert, sicher und standardisiert betreiben.
Azure Landing Zones als strategisches Fundament
Cloudprojekte starten häufig pragmatisch: Ein System wird benötigt, ein Pilotprojekt geht kurzfristig live. Doch mit wachsender Komplexität zeigt sich, dass Einzelmaßnahmen nicht skalierbar sind – besonders, wenn zentrale Fragen zu Sicherheit, Netzwerk oder Identität unbeantwortet bleiben. Azure Landing Zones adressieren genau dieses Problem und schaffen das strategische Fundament für einen nachhaltigen, sicheren Cloudbetrieb.
Eine Landing Zone ist mehr als eine technische Vorlage. Sie steht für ein ganzheitliches Architektur- und Organisationsmodell, das Infrastruktur, Governance, Sicherheit und Nachvollziehbarkeit von Anfang an systematisch integriert. So entsteht eine robuste Plattform, auf der sich unterschiedlichste Workloads – von klassischen Servern bis zu modernen Plattformdiensten – wiederholbar und kontrolliert betreiben lassen.
Zentrales Prinzip ist die klare Trennung von Aufgaben und Zuständigkeiten. Subscriptions werden funktional gegliedert, etwa für Identität und Benutzerverwaltung, Netzwerkanbindung, zentrale Plattformdienste oder produktive Workloads. Managementgruppen vererben Richtlinien, Zugriffsmodelle und Namenskonventionen konsistent und zentral. Dienste wie Monitoring, Logging und Security stehen plattformweit zur Verfügung und sorgen für Transparenz und Betriebssicherheit.
Ein moderner Cloudbetrieb baut zudem auf Automatisierung und Standardisierung. GitOps-Ansätze ermöglichen es, nicht nur Deployments, sondern auch Governance-Regeln als Code abzubilden – wiederholbar, versionierbar und auditierbar. So bleibt die Cloudumgebung skalierbar und flexibel, unabhängig davon, wie viele Teams oder Anwendungen sie nutzen. Microsofts Cloud Adoption Framework (CAF) liefert den methodischen Rahmen für dieses Vorgehen. Die Landing Zone bildet darin das Herzstück – und ist der Schlüssel zu einer Cloudstrategie, die mit den Anforderungen wächst, ohne an Governance, Sicherheit oder Übersicht einzubüßen.
Verwaltungsebenen von Azure kennen
Azure ist keine flache Ebene, sondern folgt einem klar strukturierten Hierarchiemodell. Dieses Modell ermöglicht die organisatorische und technische Trennung von Ressourcen ebenso wie die konsistente Durchsetzung von Governance. Für Azure Landing Zones bildet diese Hierarchie das Fundament: Sie ist entscheidend, um Richtlinien zentral umzusetzen, Kosten gezielt zu steuern und Verantwortlichkeiten eindeutig zu definieren.
Eine tragfähige Landing Zone nutzt alle vier Verwaltungsebenen – nicht nur technisch, sondern auch organisatorisch. Nur so lässt sich eine skalierbare, kontrollierbare und nachvollziehbare Cloudplattform etablieren.
Hierarchiespitze Management Groups
An der Spitze der Azure-Hierarchie stehen die Management Groups. Sie gruppieren mehrere Subscriptions oder weitere Management Groups logisch und ermöglichen die zentrale Vererbung von:
- Azure Policies (zum Beispiel verpflichtendes Tagging, Standortbeschränkungen, Einschränkungen für Ressourcentypen)
- Role-Based Access Control (RBAC) über ganze Subbäume sowie
- Budgetvorgaben, Namenskonventionen und Sicherheitsrichtlinien
In einer professionellen Landing-Zone-Architektur sind Management Groups nicht optional – sie sind der Kern der Governance-Strategie. Sie trennen beispielsweise Plattform-Subscriptions (etwa für Netzwerk, Identität, Management) von produktiven Workloads, Sandbox-Umgebungen oder Bereichen für das Decommissioning. So lassen sich Richtlinien, Zugriffsmodelle und Abrechnungslogik zentral verwalten und konsistent durchsetzen.
Ein zentrales Prinzip dabei: Die oberste Management Group, die sogenannte "Tenant Root Group", sollte keine produktiven Policies oder RBAC-Zuweisungen enthalten. Sie dient lediglich als organisatorisches Aggregat. Policies und Rollen sollten erst auf nachgelagerten Ebenen greifen – etwa auf "Platform", "Workloads" oder "Sandbox". So bleibt die Struktur flexibel und zukunftssicher, etwa bei der Integration neuer Unternehmenseinheiten, internationalem Wachstum oder strukturellen Anpassungen. Typische Fehler in der Praxis sehen häufig so aus:
- Keine Management Groups: Governance muss pro Subscription manuell konfiguriert werden. Das erhöht den Wartungsaufwand und führt zu inkonsistenten Vorgaben.
- Flache Hierarchie: Es fehlt die klare Trennung zwischen Plattform- und Applikationsbereichen; zukünftiges Wachstum (zum Beispiel neue Regionen oder Business Units) wird erschwert.
- Wildcard-Policies auf Root-Ebene: Diese können spätere Erweiterungen blockieren oder zu unerwünschter Richtlinienvererbung führen.
Subscriptions: Strukturieren, abrechnen, trennen
Eine Subscription ist die zentrale Einheit für Abrechnung, Ressourcenzuteilung und organisatorische Trennung in Azure. Sie verbindet die technische Bereitstellung mit der finanziellen Verantwortung: Hier sind Ressourcen verortet, hier greifen Quotas, Budgets und Richtlinien, und hier erfolgt die Abrechnung – etwa über Kreditkarte, Enterprise Agreement oder Cloud Solution Provider. Anders als Management Groups, die lediglich logische Ordnungsrahmen darstellen, sind Subscriptions aktive Container für Ressourcen und Governance. Sie definieren, wer worauf Zugriff hat, welche Policies gelten und welche Workloads betrieben werden dürfen.
Subscriptions erfüllen klar abgegrenzte Rollen: Plattformdienste wie Netzwerk, Identität oder Monitoring laufen in dedizierten Plattform-Subscriptions. Applikationsteams erhalten eigene Subscriptions, die sie innerhalb definierter Leitplanken selbst verwalten können. Dieses Modell trennt Verantwortlichkeiten, ermöglicht geteilte Nutzung zentraler Dienste und schafft eine Balance aus Kontrolle und Autonomie – ohne Abstriche bei Sicherheit oder Effizienz.
Resource Groups: Klarer Kontext
Resource Groups bündeln zusammengehörige Ressourcen wie virtuelle Maschinen, Netzwerkschnittstellen, Festplatten und Sicherheitsgruppen. Sie sind die operative Einheit für Automatisierung, Lifecycle-Management und Zugriffskontrolle – und damit essenziell für eine effiziente Nutzung der Azure-Plattform.
In einer Azure Landing Zone dienen Resource Groups nicht nur der Ordnung, sondern sind Teil eines strukturierten Modells, das Wiederverwendbarkeit, Übersichtlichkeit und Automatisierung unterstützt. Die Gliederung erfolgt praxisnah: Entweder entlang technischer Schichten (beispielsweise Infrastruktur, Daten, Applikation), Umgebungen (etwa Entwicklung, Test, Produktion) oder funktionaler Komponenten (zum Beispiel Frontend, Backend). Diese Aufteilung schafft klare Verantwortlichkeiten, vereinfacht die Infrastrukturverwaltung per Code und unterstützt ein gezieltes Monitoring.
Vorschau: Azure Service Groups
Mit den auf der Microsoft Build 2025 als Preview vorgestellten Azure Service Groups führt Microsoft eine zusätzliche Governance-Ebene ein. Sie ergänzt die bestehende Hierarchie durch eine kontextbezogene Gruppierungsmöglichkeit, die besonders für komplexe Organisationen und dynamische Plattformarchitekturen interessant ist.Service Groups ermöglichen es, Ressourcen, Resource Groups und sogar ganze Subscriptions unabhängig von der physischen Hierarchie mehrfach zu gruppieren – beispielsweise nach Workloads, Projekten oder Geschäftseinheiten. Im Unterschied zu Management Groups lassen sie sich verschachteln und mehrfach referenzieren. So entstehen mehrdimensionale Governance-Sichten, ohne dass Sie die bestehende Struktur anpassen müssen. Als mögliche Einsatzszenarien innerhalb einer Landing Zone kommen in Frage:- Ein Microservice mit verteilten Komponenten (Compute, DB, Storage) über mehrere Subscriptions lässt sich gemeinsam verwalten.- Service Owner erhalten gezielten Zugriff auf funktionsbezogene Ressourcen – unabhängig vom organisatorischen Kontext.- Monitoring- und Reportingdaten lassen sich auf Service-Group-Ebene aggregieren, etwa für Verfügbarkeit, Performance oder Kostenanalyse.Noch befindet sich die Funktion in der Preview-Phase. Der praktische Nutzen für produktive Umgebungen muss sich erst zeigen, insbesondere im Zusammenspiel mit bestehenden Azure Landing Zones, RBAC-Modellen und Automatisierungstools. Tests in isolierten Umgebungen sind sinnvoll, ein produktiver Einsatz sollte jedoch mit Bedacht erfolgen.
Ressourcen erlauben Umsetzung ohne Wildwuchs
An der Basis der Azure-Hierarchie stehen die eigentlichen Ressourcen: virtuelle Maschinen, Datenbanken, Storage Accounts, App Services, Key Vaults, Public IPs und viele mehr. Sie bilden den operativen Kern der Cloud – und zugleich eine der größten Herausforderungen bei Sicherheit, Konsistenz und Kostenkontrolle. Fehlkonfigurationen auf dieser Ebene führen schnell zu Sicherheitslücken, Wildwuchs und ineffizientem Betrieb.
Eine gut konzipierte Azure Landing Zone reduziert solche Risiken: Governance-Vorgaben wie Standortwahl, erlaubte Ressourcentypen, Verschlüsselung oder Tagging werden zentral definiert und automatisch vererbt – etwa durch Azure Policies, rollenbasierte Zugriffsmodelle und standardisierte Vorlagen. So sinkt der manuelle Aufwand, Fehlerquellen werden minimiert, und die Sicherheit steigt durch konsistente Umsetzung.
Trotzdem bleibt diese Ebene kritisch: Ressourcen sollten automatisiert bereitgestellt werden, etwa per Bicep, Terraform oder ARM Templates. Jede Ressource muss eindeutig gekennzeichnet sein, zum Beispiel mit Tags für Projekt, Verantwortliche oder Kostenstelle. Zentrale Sicherheitsmaßnahmen wie Netzwerksicherheitsgruppen, Diagnose-Logging und Backup-Policies müssen verbindlich greifen.
Die Stärke einer Landing Zone liegt darin, dass sie Governance nicht lokal entscheidet, sondern global durchsetzt. Je mehr Regeln zentral definiert und automatisiert vererbt werden, desto robuster, skalierbarer und sicherer wird die gesamte Cloudplattform.
Plattform- vs. Anwendungs- Landing-Zones
Ein häufiges Missverständnis in Azure-Projekten besteht darin, eine Landing Zone als umfassenden Bauplan für sämtliche Ressourcen zu begreifen. In Wirklichkeit handelt es sich jedoch nicht um einen monolithischen Ressourcenblock, sondern um ein architektonisches Prinzip, das in klar voneinander getrennte Zonen untergliedert ist. Diese Trennung schafft nicht nur Übersicht, sondern unterstützt Teams dabei, ihre Rollen und Verantwortlichkeiten sowohl technisch als auch organisatorisch sauber zu definieren.
Grundsätzlich lassen sich zwei Typen von Landing Zones unterscheiden. Plattform-Landing-Zones bilden das zentrale Rückgrat der Umgebung. Sie werden in der Regel von zentralen IT- oder Infrastrukturteams betrieben und beinhalten sämtliche übergreifenden Dienste. Dazu zählen beispielsweise die zentrale Netzwerkinfrastruktur mit Hub-Netzwerk, DNS und Firewalls, Identitätsdienste mit EntraID oder hybriden Lösungen sowie einheitliche Logging- und Monitoringsysteme wie Azure Monitor oder Log Analytics. Auch Backupmechanismen, Sicherheitsvorgaben und zentrale Policy-Dienste sind hier verankert. Diese Plattformzone fungiert in einem Hub-and-Spoke-Modell als zentraler Hub, der übergreifende Funktionen für sämtliche angebundenen Workloads bereitstellt – auch über Subscriptions und Netzgrenzen hinweg.
Auf der anderen Seite stehen die Anwendungs-Landing-Zones, auch bekannt als Workload- oder App-Landing-Zones. Diese sind in der Regel spezifisch für einzelne Teams oder Projekte konzipiert und werden entweder automatisiert oder im Rahmen eines Self-Service-Modells bereitgestellt. Sie sind technisch und organisatorisch von der Plattformzone entkoppelt, aber durch klare Schnittstellen mit ihr verbunden. In diesen Zonen befinden sich die eigentlichen Workloads – also Anwendungen, Datenplattformen oder Services einzelner Teams. Die Verwaltung erfolgt häufig durch DevOps-Teams, die innerhalb ihrer Zone eigenständig agieren. Die Plattform sorgt im Hintergrund dafür, dass Governance-, Netzwerk- und Sicherheitsrichtlinien konsequent eingehalten werden.
Im Idealfall funktioniert dieses Modell wie ein Plug-and-Play-Prinzip: Neue Workload-Zonen werden als vordefinierte Templates bereitgestellt (zum Beispiel per Terraform, Bicep oder Azure Landing Zone Accelerator) und dann an die bestehende Plattform-Landing Zone angebunden. Das ermöglicht
- eine skalierbare Governance, ohne jeden neuen Workload stets manuell konfigurieren zu müssen,
- eine konsistente Anbindung an zentrale Dienste und
- eine klare Trennung von Betriebsverantwortung zwischen Plattform- und Workload-Teams.
Die Plattform-Landing-Zone übernimmt dabei nicht nur technische Funktionen, sondern bildet auch die Grundlage für hybride Konnektivität – etwa durch die Anbindung an On-Premises-Netzwerke via ExpressRoute oder Site-to-Site VPN.
ALZ als Grundlage für "Secure by Default"
Sicherheit entsteht in Azure nicht durch nachträgliche Prüfungen, sondern durch konsequente Architektur und durchdachte Standards. Eine Azure Landing Zone ist daher nicht nur ein Betriebsframework, sondern von Beginn an eine Sicherheitsarchitektur mit dem Ziel "Secure by Default".
Den Rahmen dafür bilden automatisierte Leitplanken in Form von Azure Policies. Sie verhindern unverschlüsselte Storage Accounts (siehe Listing-Kasten), blockieren VMs ohne Monitoring oder schränken die Nutzung bestimmter Regionen ein. Diese Richtlinien greifen plattformweit und konsistent. Sie ersetzen manuelle Audits durch kontinuierliche Kontrolle auf Management-Group-Ebene.
Listing: Codebeispiel für Azure Policy
{
"if": {
"field": "Microsoft.Storage/storageAccounts/encryption.services.blob.enabled "equals": "false"
},
"then":
{ "effect": "deny"
}
}
Trotz zentraler Governance bleibt Flexibilität erhalten: Rollenbasierte Zugriffssteuerung bis auf Ressourcengruppenebene und automatisierte Bereitstellung standardisierter Umgebungen ermöglichen dezentrale Verantwortung ohne Kontrollverlust. Ein zentraler Control Plane – bestehend aus Rollen, Policies und Infrastructure-as-Code – sorgt dafür, dass Sicherheitsvorgaben versionierbar, Compliance nachvollziehbar und Audits effizient durchführbar bleiben.
Viele Unternehmen versuchen, bestehende On-Prem-Konzepte mit Dritttools in die Cloud zu übertragen, oft zulasten der Effizienz. Nachhaltiger ist ein Azure-nativer Ansatz mit:
- Azure Policy für Governance,
- Defender for Cloud zur Sicherheitsüberwachung und
- Entra ID für zentrale Identitäts- und Zugriffskontrolle, inklusive Conditional Access und PIM.
Von der Theorie zur Umsetzung
Eine Azure Landing Zone entsteht nicht auf Knopfdruck, sondern schrittweise. Wichtig ist ein klar strukturiertes Vorgehen – mit realistischem Zielbild, technischer Einschätzung und organisatorischer Standortbestimmung. Zu Beginn stehen zentrale Fragen:
- Welche Rolle soll Azure im Unternehmen übernehmen – Innovation, Skalierung oder Migration?
- Wie reif ist die Organisation hinsichtlich Automatisierung, Governance und Eigenverantwortung?
- Welche Workloads eignen sich für den Einstieg?
Ein initiales Assessment liefert Orientierung. Microsofts Cloud Adoption Frame-work dient dabei als Werkzeugkasten: Statt starrer Vorgaben bietet es flexible Bausteine wie Plattformdesigns, Namenskonventionen und Betriebsmodelle, die sich an die Ausgangslage anpassen lassen. Wichtig für die Umsetzung sind vor allem folgende Punkte:
- Automatisierung von Anfang an: Mit Terraform, Bicep oder Azure Verified Modules entstehen wiederverwendbare, CI/CD-fähige Bereitstellungen.
- Stabiles Fundament vor Produktivstart: Netzwerk, Identität, Sicherheit, Logging und Monitoring müssen stehen, bevor erste Workloads folgen.
- Greenfield-Prinzip: Neue Workloads zuerst ALZ-konform aufbauen, Erfahrungen sammeln, dann bestehende Systeme selektiv integrieren.
Governance, Security und FinOps sollten von Anfang an Teil der Architektur sein. Einheitliches Tagging – etwa für Kostenstelle oder Service Owner – schafft dabei Transparenz und erlaubt automatisiertes Reporting über Subscriptions hinweg.
Fazit
Azure Landing Zones sind mehr als nur ein technisches Konzept. Sie bilden die Grundlage für eine strukturierte, sichere und zukunftsfähige Cloudplattform. Wer von Beginn an mit einem klaren Architekturmodell arbeitet, schafft Transparenz, Governance und Wiederverwendbarkeit.
Eine gut geplante Landing Zone trennt Verantwortlichkeiten sauber, automatisiert wiederkehrende Aufgaben und sorgt dafür, dass Compliance, Sicherheit und Betrieb keine nachträglichen Add-ons sind. Governance wird dadurch nicht zum Bremser, sondern schafft die Voraussetzungen für verteilte Teams und dynamische Projekte. Unternehmen, die heute bewusst in eine skalierbare Plattform investieren, vermeiden Wildwuchs und schützen sich vor Sicherheitslücken.
(ln)