TLDR: Kurzantwort
Die Azure Landing Zone liefert einen standardisierten, governance-basierten Rahmen, der KMU beim schrittweisen Ausbau („start small and expand“) kosteneffizient und sicher begleitet. Ein reines Greenfield-Setup erlaubt maximale Flexibilität, verlangt aber tiefere Fachkenntnisse und höheren initialen Aufwand für Sicherheit und Compliance. Für die meisten KMU empfiehlt sich der Landing-Zone-Ansatz mit iterativer Erweiterung, während Greenfield nur bei speziellen Anforderungen wie völlig individuellen Netzwerk- oder Sicherheitsmodellen sinnvoll ist – wie aktuelle Analysen für 2025 bestätigen.
Azure Landing Zone – Überblick und Komponenten
Die Azure Landing Zone (ALZ) bildet den referenzierten Rahmen für sichere, skalierbare Multi-Subscription-Umgebungen im Cloud Adoption Framework von Microsoft. Sie gliedert sich in zwei Kernbereiche: Die Platform Landing Zone bündelt zentrale Dienste wie Identitätsmanagement, Netzwerk-Topologie und Governance-Policies. Darauf aufbauend hosten Application Landing Zones die eigentlichen Workloads – isoliert, aber an die Plattform angebunden.
Modern Cloud Infrastructure
Zukunftssichere IT-Infrastruktur für Ihr Unternehmen
Microsoft liefert die Architektur als Infrastructure-as-Code aus. Bicep und Terraform dienen als Sprachen, Azure Verified Modules (AVM) als wiederverwendbare Bausteine. Der ALZ IaC Accelerator generiert daraus Pipelines, Policy-Sets und Backend-Konfiguration automatisiert. Wer diese Module nutzt, deployt reproduzierbar und versioniert.
Für KMU empfiehlt Microsoft den Pfad „Start small and expand“. Eine minimale Management-Group-Hierarchie genügt zum Einstieg: Tenant Root Group, darunter eine Unternehmens-Management-Group, darunter zwei Kinder – Production und Non-Production. Diese Struktur lässt sich später iterativ verfeinern, etwa durch zusätzliche Landing-Zone-Archetypen oder den Portal-Beschleuniger, falls IaC-Know-how fehlt. Ein typisches KMU startet mit dieser Minimalstruktur und fügt erst bei Bedarf weitere Management Groups für Identität, Netzwerk oder Management hinzu.
Best Practices für Brownfield-Szenarien zeigen: Bestehende Subscriptions in die neue Hierarchie zu überführen, erfordert Disziplin, ist aber weit weniger aufwendig als Governance nachträglich einzuführen. Der Schlüssel liegt in Audit-Mode für Policies und schrittweiser Anbindung bestehender VNets an den neuen Hub, wie Exodata in seinen Best Practices beschreibt. Eine pragmatische Brownfield-Transformation dauert partnergestützt 8 bis 12 Wochen (2025/26).
Greenfield-Setup – Definition und typische Vorgehensweise
Ein Greenfield-Setup beschreibt den Aufbau einer Azure-Umgebung von Grund auf – ohne Altlasten, ohne vorgefertigte Framework-Komponenten. Unternehmen definieren Ressourcen, Netzwerktopologien und Sicherheitskontrollen exakt nach ihren Anforderungen. Diese Gestaltungsfreiheit ist der größte Vorteil: Architekturentscheidungen lassen sich ohne Kompromisse treffen, technische Schulden entstehen gar nicht erst.
Der Preis dafür ist ein höherer initialer Aufwand. Governance, Identitätsmanagement und Netzwerkdesign müssen vollständig selbst erstellt und validiert werden. Wer hier Kürzungen vornimmt, zahlt später mit Inkonsistenzen oder Sicherheitslücken. Ein pragmatischer Weg führt über eine minimale Management-Group-Hierarchie (Tenant Root → Unternehmens-MG → Prod/Non-Prod), die sich später selektiv verfeinert. Microsoft und Community raten KMU ausdrücklich zum Start small and expand
-Pfad: erst die Plattform-Grundlage legen, dann Workloads in Wellen migrieren.
Typische Schritte umfassen:
- Management Groups und Subscription-Archetypen definieren
- Hub-Spoke-Netzwerk mit zentralem Firewall- und DNS-Hub aufbauen
- Policy-Sets initial im Audit-Mode bereitstellen, dann schrittweise erzwingen
- Identitätsbasis (Entra ID, PIM, Conditional Access) vor ersten Workloads härten
- Infrastructure-as-Code-Pipelines (Bicep/Terraform mit Azure Verified Modules) etablieren
Der Aufwand lohnt sich besonders, wenn keine Bestandsmigration ansteht und das Team IaC-Kompetenz mitbringt. Fehlt diese Expertise, kann ein Landing-Zone-Beschleuniger die Lücke schließen, ohne die Gestaltungsfreiheit aufzugeben. Am Ende steht eine Umgebung, die exakt zum Unternehmen passt – nicht zum Framework.
Direktvergleich: Azure Landing Zone vs. Greenfield (Tabelle)
Die Entscheidung zwischen Landing Zone und Greenfield hängt von der Ausgangslage ab. Sechs Kriterien zeigen, wo die Unterschiede im Tagesgeschäft liegen.
| Kriterium | Azure Landing Zone | Greenfield-Setup |
|---|---|---|
| Implementierungsaufwand | Standardisierte Module (Bicep/Terraform) und Deployment Stacks reduzieren manuelle Schritte. Start-small-Pfad erlaubt iterative Erweiterung. | Volle Freiheit bei Architekturentscheidungen, aber jede Governance-Komponente (Policy, RBAC, Netzwerk) muss selbst entworfen und getestet werden. |
| Governance-Reifegrad | Policy-Sets, Management-Groups und Diagnose-Logik sind ab Tag 1 konsistent. Compliance-Berichte lassen sich automatisiert erzeugen. | Reifegrad wächst mit dem Team. Ohne Vorgaben entstehen oft Insellösungen, die später teuer konsolidiert werden müssen. |
| Skalierbarkeit | Platform-Landing-Zone trennt Identität, Netzwerk und Management. Neue Application-Landing-Zones docken per Design an. | Skaliert nur, wenn Skalierbarkeit von Beginn an mitgedacht wird. Nachträgliche Umbauten an Subscription-Hierarchie sind aufwendig. |
| Kostenstruktur | Einmaliger Aufbauaufwand für Platform Layer, danach geringe Marginalkosten pro Workload. Phasenweise Migration verteilt Investitionen. | Keine initiale Platform-Investition, aber wiederkehrender Overhead für individuelle Governance pro Projekt. Langfristig oft höher. |
| Zeit bis produktive Nutzung | Mit ALZ Accelerator in Tagen bis Wochen einsatzbereit. Erste Workloads laufen parallel zum Platform-Ausbau. | Schnell für einzelne Workloads, aber ohne gemeinsame Basis verzögert sich jedes Folgeprojekt durch fehlende Standards. |
| Flexibilität für Sonderanforderungen | Extension Points (Custom Policies, eigene Archetypen) erlauben Anpassungen, ohne das Fundament zu brechen. | Maximale Freiheit, aber jede Abweichung schafft technischen Schuldenberg, der spätere Standardisierung behindert. |
Für KMU mit begrenzter Cloud-Erfahrung wiegt der Governance-Vorteil der Landing Zone schwer. Wer hingegen eine einzelne, klar umrissene Applikation migriert und keine weitere Expansion plant, kann mit Greenfield schneller starten – zahlt aber später den Integrationsaufwand.
Wann Azure Landing Zone die bessere Wahl ist – Use Cases
Die Azure Landing Zone eignet sich für KMU, die eine sichere Cloud-Grundlage zügig aufbauen müssen und über begrenzte interne Cloud-Expertise verfügen. Der Referenzrahmen liefert vorgefertigte Governance, Identitätsmanagement und Netzwerkarchitektur – Teams müssen das Rad nicht neu erfinden. Typische Workloads wie Web-Applikationen oder SQL-Datenbanken lassen sich direkt in die Application Landing Zones einbetten, während Compliance-Anforderungen wie die DSGVO-konforme Datenhoheit über Policy-Sets automatisiert durchgesetzt werden.
Der „Start small and expand“-Pfad erlaubt einen minimalen Einstieg mit einer einzigen Management-Group-Hierarchie (Tenant Root → Unternehmen → Prod/Non-Prod). Später werden weitere Application Landing Zones angehängt, ohne die Plattform-Schicht anzutasten. Das reduziert Initialaufwand und Risiko. Wer Infrastructure-as-Code nutzt, profitiert von Azure Verified Modules und dem ALZ IaC Accelerator – Pipelines, Policy-Sets und Backend-Konfiguration werden automatisiert bereitgestellt. Ein praxisnahes Beispiel zeigt, wie sich Landing Zones mit Terraform automatisieren lassen und so wiederholbare Deployments ermöglichen.
Für regulierte Branchen bietet die Sovereign Landing Zone zusätzliche Kontrollen wie MHSM und Confidential VMs. Der Aufbau auf einer bestehenden ALZ kostet 75.000 bis 150.000 € für Assessment, Platform Layer und initiales Policy-Set (2026, zzgl. Laufkosten für MHSM und Confidential VMs). KMU starten jedoch oft schlank: erste Workloads migrieren, Governance im Audit-Mode testen, dann schrittweise schärfen. So wächst die Umgebung organisch mit den Geschäftsanforderungen. Vendor-Angaben (Kanerika, ungeprüft) nennen 50 % schnelleren Time-to-Market in Finance/Healthcare sowie 30 % Projektzeit-Reduktion – diese Werte sind Marketing-Claims ohne unabhängige Validierung.
Wann Greenfield-Setup die bessere Wahl ist – Use Cases
Ein Greenfield-Aufbau lohnt sich, wenn Architekturen gefordert sind, die der Standardrahmen der Landing Zone nicht abbildet. Eigene Netzwerktopologien oder spezifische Sicherheitsmodelle lassen sich ohne Kompromisse umsetzen, statt sie in vorgegebene Policies zu pressen. Wer bereits tiefes Azure-Know-how im Team hält, profitiert von vollständiger Kontrolle über jede Ressource – ohne Abstriche bei Governance-Vorgaben, die für andere Organisationen sinnvoll sind.
Kurzfristige Proof-of-Concept-Projekte bilden ein weiteres starkes Szenario. Hier zählt Geschwindigkeit: Eine schlanke Umgebung ohne Overhead steht in Minuten bereit, während die Landing Zone erst Bootstrap, Policy-Sets und Management-Groups erfordert. Laut Erfahrungswerten aus Brownfield-Projekten verursacht die Migration bestehender Strukturen oft mehr Aufwand als ein sauberer Neubau – Greenfield vermeidet diesen Ballast von Anfang an.
Auch bei regulatorischen Sonderwegen, die keine Standard-Policy abdeckt, schafft ein eigener Aufbau Klarheit. Teams definieren Guardrails exakt nach Bedarf, statt generische Regeln anzupassen. Cloud-Architekten empfehlen Greenfield daher gezielt für Szenarien, in denen Standardisierung eher hemmt als hilft. Entscheidend bleibt: Das Team muss die operative Verantwortung für alle Komponenten tragen können und wollen.
Microsoft 365 zum Festpreis
Effiziente Zusammenarbeit und produktives Arbeiten mit Microsoft 365
Implementierungsschritte für KMU – Schritt-für-Schritt-Plan
Der Aufbau einer Azure Landing Zone folgt bei KMU einem dreistufigen Fahrplan, der Risiko und Aufwand beherrschbar hält. Zunächst definieren Sie die Management-Group-Hierarchie: Tenant Root Group, darunter eine Unternehmens-Gruppe, dann getrennte Zweige für Produktion und Nicht-Produktion. Diese Minimalstruktur genügt für den Einstieg und lässt sich später gezielt verfeinern, wie Microsoft in den Implementierungsoptionen darstellt.
Im zweiten Schritt richten Sie die Platform Landing Zone ein. Sie bündelt zentrale Identität (Entra ID, Conditional Access), Hub-Spoke-Netzwerk mit Azure Firewall sowie Policy-Sets für Tagging, Standortbeschränkungen und Diagnoseeinstellungen. Deployen Sie diese Basis per Infrastructure-as-Code – Bicep oder Terraform –, und nutzen Sie Azure Verified Modules (AVM) für wiederverwendbare, getestete Bausteine. Der ALZ IaC Accelerator generiert dazu Pipelines, Backend-Konfiguration und Policy-Zuordnungen automatisiert.
Danach entstehen die ersten Application Landing Zones für Prioritäts-Workloads. Wählen Sie Anwendungen mit geringem Abhängigkeitsgrad und klaren Verantwortlichkeiten. Jede Zone erhält eigenes Abonnement, dedizierte RBAC-Rollen und Anschluss an das zentrale Hub-VNet. Testen Sie Policy-Wirkung zunächst im Audit-Modus; so erkennen Sie Verstöße ohne Produktionsunterbrechung.
Die Migration bestehender Arbeitslasten erfolgt wellenweise. Azure Migrate liefert Inventar und Abhängigkeitskarte. Starten Sie mit Low-Risk-Systemen (Dev/Test, interne Tools), definieren Sie Rollback-Kriterien pro Welle und führen Sie Parallelbetrieb durch. Erst nach erfolgreicher Validierung schwenken Sie DNS und Traffic um. Dokumentieren Sie jede Welle als Repeatable Pattern – so skaliert der Prozess ohne ständiges Neuerfinden.
Fazit & Empfehlung für KMU
Für die meisten kleinen und mittleren Unternehmen liefert die Azure Landing Zone einen ausgewogenen Kompromiss aus Sicherheit, Skalierbarkeit und begrenztem Initialaufwand. Der von Microsoft empfohlene „Start small and expand“-Pfad erlaubt es, Governance-Strukturen schrittweise aufzubauen, statt die gesamte Plattform auf einmal bereitzustellen. Wer bereits Azure-Ressourcen betreibt, kann bestehende Subscriptions in eine Management-Group-Hierarchie überführen und Policies zunächst im Audit-Mode testen – das reduziert Risiken und Kosten.
Ein reines Greenfield-Setup rechtfertigt sich nur, wenn spezielle architektonische Vorgaben oder tiefes Cloud-Know-how im Haus einen vollständig individuellen Aufbau erfordern. Ohne diese Voraussetzungen steigt der Aufwand für Design, Implementierung und langfristige Wartung überproportional. Die Landing Zone hingegen stellt bewährte Patterns für Identität, Netzwerk und Policy-Management bereit, die sich über Azure Verified Modules automatisiert ausrollen lassen.
Die Entscheidung sollte entlang konkreter Use-Cases und einer realistischen Umsetzungsroadmap fallen: Welche Workloads migrieren zuerst? Welche Compliance-Anforderungen bestehen? Wie viel IaC-Expertise steht intern zur Verfügung? Für KMU mit begrenzten Ressourcen bietet der referenzierte Standardrahmen den schnelleren Einstieg in eine governable Cloud-Umgebung, während Greenfield-Projekte eher für Organisationen mit dedizierten Plattform-Teams und ausgeprägten Individualisierungsbedarf geeignet sind.
