Ich verstehe Azure Landing Zones einfach nicht.
Ein Satz, der mir immer wieder begegnet
Azure Landing Zones — einfach erklärt
Und ehrlich gesagt: Ich kann’s nachvollziehen. Cloud-Architektur klingt abstrakt — aber was wäre, wenn wir sie wie einen klassischen Serverraum denken?
Was ist eine Azure Landing Zone?
Eine Azure Landing Zone ist die vorbereitete Umgebung, in die Anwendungen später einziehen — mit Netzwerk, Zugriffsregeln, Namenskonventionen und Kostenzuordnung, bevor die erste virtuelle Maschine startet. Nicht die Anwendung selbst, sondern der Rahmen, in dem sie sicher und nachvollziehbar betrieben werden kann.
Der Begriff stammt aus dem Microsoft Cloud Adoption Framework. Er beschreibt keine einzelne Technologie, sondern ein Bündel aus Entscheidungen, die man einmal trifft und danach nicht mehr jedes Mal neu diskutiert.
Die vier Fragen, die eine Landing Zone beantwortet
Wie ist das Ganze gegliedert?
Management Groups fassen Subscriptions zusammen, Subscriptions bündeln Resource Groups, darin liegen die eigentlichen Ressourcen. Diese Hierarchie entscheidet, wo Regeln greifen und wie Kosten zugeordnet werden.
Wer darf was?
Zugriffsrechte werden über Rollen vergeben, nicht über einzelne Personen. Wer eine Aufgabe übernimmt, bekommt die Rolle — wer sie abgibt, verliert sie automatisch.
Wie fließt der Verkehr?
Das Netzdesign legt fest, welche Bereiche miteinander sprechen dürfen. Das gängige Muster heißt Hub-and-Spoke: ein zentraler Bereich mit gemeinsamen Diensten, daran angebunden die einzelnen Arbeitsbereiche.
Was ist erlaubt?
Azure Policy prüft jede Ressource beim Anlegen gegen die festgelegten Regeln — welche Regionen zulässig sind, welche Verschlüsselung Pflicht ist, welche Kennzeichnungen fehlen dürfen und welche nicht.
Warum das vor dem ersten Projekt geklärt sein sollte
Eine Landing Zone lässt sich nachträglich bauen. Nur wird sie dann teuer.
Trifft Entscheidungen unter Zeitdruck
Jede Ressource, die bereits läuft, muss umgezogen, neu benannt oder neu berechtigt werden — im laufenden Betrieb, mit allen Abhängigkeiten, die inzwischen entstanden sind.
Trifft dieselben Entscheidungen einmal
Struktur, Rollen, Regeln, Netzdesign werden vor dem ersten produktiven Workload festgelegt. Danach wird nicht mehr im Einzelfall verhandelt, sondern der Rahmen wird genutzt.
Wie sich diese vier Bereiche anfühlen, wenn man sie sich als Gebäude vorstellt, zeigt der folgende Abschnitt.
Erst planen, dann ausstatten
Niemand stellt ein Serverrack in einen Raum, ohne vorher nachgedacht zu haben. Genau diese Überlegungen fehlen bei Cloud-Projekten erstaunlich oft — obwohl sie dieselben sind.
Bevor der erste Server in einen Raum kommt, klärt man eine Reihe von Fragen. Wo steht der Raum überhaupt? Erdgeschoss oder Keller, Hochwassergefahr, wie weit zum nächsten Stromanschluss. Wie viele Racks passen hinein, und wie viel Platz bleibt zum Nachrüsten? Wie viele Server pro Rack, und trägt die Kühlung das auch im Sommer?
Dann die Fragen, an die man erst denkt, wenn etwas passiert: Welche Löschanlage — Wasser zerstört, was sie retten soll, also Gas. Wer kommt im Notfall hinein, und wie schnell? Was passiert bei Stromausfall — überbrückt die unterbrechungsfreie Versorgung lange genug, bis das Notstromaggregat läuft?
Keine dieser Fragen betrifft einen einzelnen Server. Alle betreffen den Rahmen, in dem Server später stehen.
Und genau das ist eine Landing Zone. Wo liegen die Daten — welche Region? Wie viele Subscriptions brauchen wir, und wie schneiden wir sie? Was passiert, wenn jemand versehentlich eine Ressource in der falschen Region anlegt — greift eine Regel, oder merkt es niemand? Wer kommt im Notfall an die Umgebung, und wie wird das protokolliert?
Der Unterschied zum Serverraum ist nur, dass man in der Cloud jederzeit weiterbauen kann. Das klingt nach Freiheit, ist aber die eigentliche Gefahr: Im Serverraum zwingt der Platzmangel zur Planung. In der Cloud kann man beliebig lange ohne Ordnung wachsen — und merkt es erst, wenn niemand mehr sagen kann, wem welche Ressource gehört und was sie kostet.
Wer das Bild größer denken möchte: In Sofian’s City wird dieselbe Landschaft als ganze Stadt beschrieben — mit Identitäts-Rathaus, Verkehrsführung und Bauordnung. Die Landing Zone ist darin die Bauordnung, die festlegt, was überhaupt gebaut werden darf.
Zwei Welten, eine Logik
Die Prinzipien eines gut geplanten Serverraums lassen sich fast eins zu eins auf eine Azure Landing Zone übertragen. Wer das eine kennt, hat den Einstieg ins andere bereits geschafft.
Dieselbe Logik · anderes Medium
Darstellung: eigene Grafik, KI-gestützt erstellt
Achtzehn Konzepte,
achtzehn Übersetzungen
Jede Ebene der Azure Landing Zone hat ihr direktes Gegenstück im Serverraum. Wenn Sie diese achtzehn Zuordnungen einmal verinnerlicht haben, wird der Rest der Cloud-Terminologie plötzlich intuitiv.
Das Gebäude
Der übergeordnete Rahmen, in dem alles steht. Adresse, Zutritt, Verantwortung sind hier verankert.
Subscription
Die oberste Abrechnungs- und Verwaltungseinheit. Alles darunter gehört organisatorisch zu einer Subscription.
Das Serverrack
Bündelt Server, die logisch zusammengehören — nach Anwendung, Umgebung oder Team.
Resource Group
Gruppiert Azure-Ressourcen, die einen gemeinsamen Lebenszyklus, Standort oder Verantwortlichen teilen.
Die einzelnen Server
Die Arbeitspferde: physische Maschinen mit CPU, RAM, Storage und einer klar definierten Aufgabe.
Resources
Virtuelle Maschinen, Storage Accounts, App Services, SQL-Datenbanken — alles, was Compute oder Storage liefert.
Der Gebäudekomplex
Mehrere Gebäude auf einem Campus, die gemeinsam verwaltet werden — mit übergeordneten Regeln für alle Standorte.
Management Group
Bündelt mehrere Subscriptions und vererbt Policies und Zugriffsrechte hierarchisch nach unten.
Die Raumbeschriftung
Inventaraufkleber und Türschilder — auf einen Blick erkennbar, wozu ein Raum gehört und wer zuständig ist.
Tags
Metadaten wie Kostenstelle, Umgebung oder Owner, die an Ressourcen hängen — wichtig für Abrechnung und Ordnung.
Die Bauvorschriften
Brandschutz, Fluchtwege, Statik — Vorgaben, die beim Bau automatisch eingehalten werden müssen, ohne Diskussion im Einzelfall.
Azure Policy
Erzwingt Regeln automatisch — etwa erlaubte Regionen oder Pflicht-Tags — und verhindert Abweichungen direkt bei der Erstellung.
Der Hauptschlüssel
Öffnet alle Türen. Wer ihn hat, kann überall rein — Segen und Risiko zugleich.
Owner-Rolle
Volle Kontrolle über alle Ressourcen — inklusive Berechtigungsvergabe. Sparsam einsetzen und über PIM absichern.
Die Zugangskontrolle
Kartensysteme, Türcodes, Videoüberwachung — regelt, wer welchen Raum betreten darf und wann.
Azure RBAC
Role-Based Access Control regelt granular, welche Identität welche Aktion auf welchem Scope ausführen darf.
Das Speichersystem
SAN und NAS im Serverraum: die zentrale Ablage für Dateien und Datenbanken — mit RAID gegen den Plattenausfall.
Storage Account
Zentraler Speicher für Blobs, Dateien, Tabellen und Warteschlangen — Redundanz per Konfiguration statt per RAID-Controller.
Das Monitoring
Alarme, Sensoren, Temperatur- und Stromüberwachung: Störungen sollen auffallen, bevor jemand sie meldet.
Azure Monitor
Metriken, Logs und Alarme für alle Ressourcen — die Sensorik der Cloud, inklusive Benachrichtigung, bevor etwas ausfällt.
Der Tresor
Zertifikate, Schlüssel und Wertsachen liegen nicht im Regal, sondern im Tresor — mit dokumentiertem Zugriff.
Key Vault
Verwahrt Secrets, Zertifikate und Schlüssel zentral; Anwendungen holen sie zur Laufzeit ab, statt sie im Code zu tragen.
Der Notfallschlüssel
Im versiegelten Kasten für den Ernstfall: Wenn Kartensystem oder Schließanlage versagen, kommt man trotzdem hinein.
Break-Glass-Konto
Ein Notfallzugang außerhalb der normalen Regeln — streng überwacht, dokumentiert und ausschließlich für den Ernstfall.
Die Verkabelung
Netzwerkverkabelung, Switches und Router — sie legen fest, welche Bereiche im Haus miteinander sprechen dürfen.
Virtual Network
VNet, Peering, Gateways und NSGs — das innere Verbindungsnetz, das den Verkehr zwischen den Ressourcen steuert.
Die Backup-Bänder
Regelmäßige Sicherungen auf Bändern, gelagert im externen Tresor oder am Disaster-Recovery-Standort.
Azure Backup
Azure Backup, Site Recovery und Geo-Redundanz — versionierte Sicherungen, an einem geografisch getrennten Ort abgelegt.
Der Zweitstandort
Mehrere Gebäude in verschiedenen Städten oder Campus-Teile mit unabhängiger Strom- und Netzversorgung.
Regions & Availability Zones
Multi-Region-Deployment und Availability Zones — damit ein Ausfall an einem Ort nicht alles lahmlegt.
Der Bauplan
Blaupause, Statik-Berechnung und dokumentierte Aufbau-Verfahren — kein seriöses Bauprojekt startet ohne sie.
Infrastructure as Code
Bicep, Terraform, ARM-Templates und Pipelines — die Landing Zone wird in Code beschrieben, versioniert und wiederholbar aufgebaut.
Der Prüfbericht
Regelmäßige Sicherheitsinspektionen, Audit-Berichte und Nachweise für Zertifizierungen.
Compliance Manager
Azure Compliance Manager, Audit Logs und Defender for Cloud — der Nachweis, dass Regeln nicht nur aufgeschrieben, sondern eingehalten werden.
Die Grundstücksgrenze
Wo das Gebäude physisch steht — welches Recht am Standort gilt und wer aus welchem Rechtsraum Zugriff hat.
Data Residency
Region-Bindung, EU Data Boundary und Microsoft Cloud for Sovereignty — in welchem Rechtsraum die Daten liegen und wer darauf zugreifen darf.
Gute Architektur beginnt immer mit Struktur
Niemand baut einen Serverraum, indem er wahllos Server in einen leeren Raum stellt. Es gibt Pläne für Kühlung, Kabelführung, Redundanz, Zutritt. Erst wenn dieses Fundament steht, ziehen die Server ein.
Eine Azure Landing Zone ist genau dieses Fundament — nur digital. Sie definiert vor der ersten produktiven Workload, wie Identity, Netzwerk, Governance, Security und Compliance ineinandergreifen. Wer diese Basis überspringt, baut Technikschulden, die sich später nur teuer zurückzahlen lassen.
01 · Identity
Wer darf was?
Entra ID, PIM, Conditional Access — die Zugriffsschicht wird einmal sauber gebaut, nicht pro Projekt neu erfunden.
02 · Network
Wie fließt der Verkehr?
Hub-and-Spoke, Private Endpoints, Firewall-Policies — die Netzwerktopologie ist tragende Wand, nicht Detail.
03 · Governance
Was ist erlaubt?
Policies, Blueprints, Management Groups — Regeln, die für alle gelten und automatisch durchgesetzt werden.
Welche Analogien nutzen Sie, um komplexe Cloud-Konzepte greifbar zu machen?
Mehr aus der Klartext-Serie
Alle Ausgaben →RBAC ist wie ein Hausmeister-Schlüsselbund
Warum granulare Rollen im echten Leben genauso funktionieren wie in Azure.
◦ In VorbereitungHub-and-Spoke ist wie ein Firmenshuttle
Netzwerktopologien mit einem Blick auf das Werksverkehrssystem verstehen.
◦ In VorbereitungAzure Policies sind wie eine Hausordnung
Warum Regeln, die automatisch durchgesetzt werden, jede Diskussion überflüssig machen.
◦ In Vorbereitung