Azure Landing Zones pragmatisch umgesetzt: Wie viel Plattform-Governance braucht es wirklich?

Die meisten Azure-Umgebungen beginnen mit einem einzelnen Projekt, etwa einer neuen Anwendung, einem internen Portal oder einem ersten Schritt in die Cloud. Am Anfang möchte das Team vor allem Nutzen schaffen, nicht eine umfangreiche Struktur aufbauen.

Mit weiteren Anwendungen, Teams und Schnittstellen wachsen jedoch die wiederkehrenden Fragen zu Zugriffen, Kosten, Sicherheit und Betrieb. Microsoft bezeichnet jede solche fachliche oder technische Einheit als Workload, also zum Beispiel eine Anwendung, einen Dienst, eine Integration, ein KI-System oder eine Datenplattform. Wenn jedes Projekt diese Fragen neu beantwortet, entstehen unterschiedliche Vorgehensweisen und zusätzlicher Abstimmungsaufwand. Genau hier hilft eine Azure Landing Zone.

Was ist eine Azure Landing Zone?

Eine Azure Landing Zone ist der Unterschied zwischen einer leeren Azure Subscription und einem klaren Startpunkt für ein neues Projekt. Eine Subscription ist zunächst nur ein Verwaltungs- und Abrechnungsbereich. Sie bietet Platz für Azure-Ressourcen wie Webanwendungen, Datenbanken oder Speicher, beantwortet aber noch nicht, wer Zugriff erhält, wie Kosten zugeordnet werden oder was im Fehlerfall passiert.

Stell dir ein Team vor, das ein Kundenportal in Azure bereitstellt. Ohne Landing Zone beginnt es mit einer leeren Subscription und muss diese Fragen selbst entscheiden. Mit Landing Zone steht vor der ersten Ressource fest, wo Entwicklung und Produktion laufen, wer Kosten und Risiko verantwortet, wer Änderungen vornehmen darf und wer bei einer Störung informiert wird.

Sie ist weder nur Dokumentation noch nur ein Satz vorhandener Azure-Ressourcen. Eine Landing Zone verbindet Vereinbarungen, technische Einstellungen und einen klaren Ablauf für neue Projekte:

• Vereinbarungen: Fachliche und technische Verantwortliche, Sicherheitsregeln und der Umgang mit Ausnahmen sind festgelegt.
• Struktur und Zugriffe: Subscriptions trennen bei Bedarf Produktion und Entwicklung, Gruppen erhalten die nötigen Berechtigungen und Tags ordnen Kosten zu.
• Leitplanken für den Betrieb: Budgets, wenige verbindliche Regeln sowie Logging und Alarme machen Kosten, Risiken und Störungen sichtbar.
• Ein wiederholbarer Start: Ein neues Projekt liefert die nötigen Angaben und erhält diese Grundlagen nach einem festen Ablauf, später auch automatisiert als Infrastructure as Code, also als versionierte Beschreibung der Azure-Einstellungen.

Nicht jeder Baustein gehört vom ersten Tag an dazu. Für das Kundenportal reichen klare Verantwortlichkeiten, getrennte Bereiche für Produktion und Entwicklung, Gruppen für Zugriffe, Kostentransparenz sowie Protokolle und Alarmwege. Gemeinsame Dienste für Monitoring, Sicherheit oder Netzwerkverbindungen kommen hinzu, wenn mehrere Anwendungen sie tatsächlich brauchen.

Damit ist eine Landing Zone kein Selbstzweck. Sie verhindert, dass jedes Team die Grundlagen für sein Projekt neu aushandeln muss. Wie dieser kleinste sinnvolle Startpunkt konkret aussieht, zeigen die nächsten Abschnitte.

Woran du erkennst, dass das Thema relevant wird

Eine Landing Zone ist nicht erst für große Unternehmen sinnvoll. Wenn zwei oder drei der folgenden Punkte zutreffen, lohnt sich meist eine schlanke gemeinsame Basis:

• Mehrere Anwendungen oder Teams arbeiten in Azure.
• Es gibt mehrere Subscriptions oder die erste weitere Subscription ist absehbar.
• Berechtigungen, Kosten oder Zuständigkeiten werden immer wieder diskutiert.
• Kundenvorgaben, gesetzliche Anforderungen oder sensible Daten erfordern nachvollziehbare Regeln.

Der nächste Schritt ist nicht automatisch eine umfangreiche Plattform. Zuerst hilft es, die wiederkehrenden Entscheidungen für das nächste Projekt klar festzuhalten.

Warum Microsofts Referenz groß aussieht

Wer nach Azure Landing Zones sucht, sieht schnell ein umfangreiches Microsoft-Schaubild mit getrennten Bereichen für Identitäten, Sicherheit, Management, Netzwerke und Anwendungen. Die Azure-Landing-Zone-Dokumentation beschreibt damit ein anpassbares Zielbild für Organisationen mit vielen Anwendungen, Teams oder strengen Anforderungen.

Das Bild ist groß, weil es Antworten auf Situationen enthält, die ein kleines Team noch nicht hat. Es zeigt mögliche gemeinsame Dienste und getrennte Zuständigkeiten, nicht die Pflichtausstattung für den ersten Tag. Dabei ist es bewusst groß gewählt, um die Vielfalt der Optionen zu zeigen. Das heißt nicht, dass von Anfang an alles aus dem Bild umgesetzt werden muss.

Eigene Bereiche für zentrale Sicherheit, Netzwerkbetrieb oder Identitätsverwaltung werden erst sinnvoll, wenn ein Team sie betreibt und mehrere Anwendungen davon profitieren. Vorher erzeugen sie oft mehr Pflegeaufwand als Nutzen. Die bessere Frage lautet daher nicht, welche Kästen aus dem Bild fehlen, sondern welche wiederkehrende Arbeit ein zusätzlicher Baustein tatsächlich reduziert.

Die kleinste sinnvolle Landing Zone

Ein kleines Team braucht keine große Plattformorganisation, um einen brauchbaren Startpunkt zu schaffen. Für eine wichtige Anwendung reichen oft wenige, klar gepflegte Bausteine. Sie geben dem nächsten Projekt Orientierung, ohne die vorhandene Umgebung unnötig umzubauen.

Produktion, Entwicklung und Erprobung trennen

Für den Anfang ist häufig eine Subscription für Produktion und eine für Entwicklung und Tests sinnvoll. Sie dienen als klare Grenzen für Kosten, Zugriffe und Regeln.

Eine optionale Sandbox Subscription, also eine getrennte Umgebung zum Ausprobieren, gibt dem Team Raum für Experimente. Bei mehreren sehr kleinen Anwendungen mit denselben Verantwortlichen kann eine gemeinsame Subscription zunächst ausreichen. Eine weitere Grenze lohnt sich, wenn sich Verantwortliche, Nutzungsdauer, Sicherheitsanforderungen oder Kostenverantwortung unterscheiden.

Der Leitfaden für erste Azure Subscriptions von Microsoft beschreibt ähnliche Trennungen. Entscheidend ist nicht die Zahl der Subscriptions, sondern dass ihre Aufgabe verständlich bleibt.

Zugriffe über Gruppen steuern

Microsoft-Entra-Gruppen fassen Menschen nach ihrer Aufgabe zusammen, etwa Entwicklung, Betrieb oder Kostenverantwortung. Diese Gruppen erhalten die nötigen Berechtigungen in Azure, nicht einzelne Personen direkt.

So bleibt nachvollziehbar, wer warum Zugriff hat. Eine neue Kollegin wird der passenden Gruppe zugeordnet, statt an vielen Stellen Berechtigungen zu erhalten. Weitreichende Rechte für die ganze Subscription bleiben die Ausnahme und sollten zeitlich begrenzt sein.

Kosten und Betrieb sichtbar machen

Tags sind zusätzliche Kennzeichnungen an Ressourcen, beispielsweise für Anwendung, Umgebung und Kostenstelle. Zusammen mit einem Budget schaffen sie die Grundlage für nachvollziehbare Kosten. Ein Budget warnt bei Verbrauch oder Prognosen, stoppt aber keine Ressourcen automatisch. Darum braucht jede Warnung einen Empfänger und eine vereinbarte Reaktion.

Für produktive Systeme gehören zentrale Protokolle und klare Alarmwege dazu. Das Team muss im Störungsfall sehen können, was passiert ist, und wissen, wer handelt. Ebenso wichtig sind ein angemessener Aufbewahrungszeitraum für relevante Daten und ein getesteter Weg zur Wiederherstellung.

Wenige Regeln, die wirklich helfen

Azure Policy kann einfache Plattformregeln durchsetzen oder auf Abweichungen hinweisen, etwa verpflichtende Tags oder erlaubte Azure-Regionen. Starte mit wenigen Regeln, deren Nutzen das Team versteht. Neue Regeln prüfst du idealerweise zunächst sichtbar, bevor sie Bereitstellungen blockieren.

Eine Ausnahme braucht eine Begründung, eine verantwortliche Person und ein Ablaufdatum. Damit wird sie zu einer bewussten Entscheidung statt zu einer stillen Sonderlösung. Wenn du die Mechanik dahinter vertiefen willst, helfen unsere Artikel Azure Policy verstehen und Azure Policy als Code pflegen.

So wächst eine Landing Zone mit der Organisation

Eine Landing Zone hat keine feste Ausbaustufe. Sie sollte wachsen, wenn wiederkehrende Aufgaben, Risiken oder Anforderungen wachsen. Die folgenden Phasen sind kein Reifegradtest, sondern eine Orientierung für typische Entscheidungen.

Stufe 1: Ein Team und wenige Anwendungen

In der ersten Stufe reichen die beschriebene Trennung von Produktion und Entwicklung, klar benannte Verantwortliche, Entra-Gruppen, Tags, Budgets, zentrale Protokollierung und wenige Regeln. Ein kurzes Ticket oder Formular für ein neues Projekt hält fest, wer verantwortlich ist, welches Budget gilt und welche Zugriffe oder Daten besonders zu beachten sind.

Die Baseline darf anfangs jedes Team für sich einrichten. Dabei sollte aber schon Infrastructure as Code mit Werkzeugen wie Bicep oder Terraform eingeplant werden. So werden schon Änderungen nachvollziehbar, ohne dass schon ein eigenes Plattformteam nötig ist.

Stufe 2: Mehrere Teams und gemeinsame Aufgaben

Mit mehreren Teams entstehen oft gleiche Anforderungen an Alarme, Security oder den Weg zu einer neuen Subscription. Jetzt lohnen sich gemeinsame Module für Infrastructure as Code, ein standardisierter Antrag für neue Projekte und klar verantwortete Dienste für Monitoring oder Sicherheit.

Management Groups helfen, gemeinsame Regeln über mehrere Subscriptions hinweg anzuwenden. Die meisten kleineren Umgebungen kommen lange mit einer sehr einfachen Struktur aus.

Stufe 3: Viele Anwendungen und zentrale Plattformfähigkeiten

Bei vielen Anwendungen, regulierten Daten oder mehreren Standorten können dedizierte Teams für Sicherheit, Netzwerk und Plattformbetrieb sinnvoll werden. Ein Hub-and-Spoke-Netzwerk verbindet dann getrennte Anwendungsnetze über gemeinsam betriebene Netzwerkdienste, beispielsweise kontrollierte Verbindungen ins eigene Rechenzentrum oder die eigenen Server.

Hub-and-Spoke bringt zusätzliche Betriebsaufgaben mit sich und lohnt sich erst, wenn mehrere Anwendungen gemeinsame Netzwerkdienste benötigen. Die Hub-and-Spoke-Referenzarchitektur ist deshalb eine spätere Option, nicht der automatische nächste Schritt.

Klein anfangen und bewusst wachsen

Zwei Fehler begegnen Teams besonders häufig. Manche bauen zentrale Subscriptions, komplexe Netzwerke und Freigabeprozesse auf, bevor es dafür mehrere Nutzer oder einen klaren Betrieb gibt. Andere lassen alle Entscheidungen offen, bis unklare Ownership, fehlende Protokolle oder überraschende Kosten unter Zeitdruck bereinigt werden müssen.

Den größten Nutzen mit wenig Aufwand schaffen meist klar benannte Verantwortliche, Gruppen statt Einzelberechtigungen, Kosten-Tags, Budgets, zentrale Protokollierung und ein kurzer Startprozess für neue Projekte. Plane auch Ausnahmen und das Ende einer Anwendung ein. Eine dokumentierte Ausnahme mit Ablaufdatum und ein klarer Weg zum Entfernen nicht mehr benötigter Ressourcen verhindern, dass Sonderfälle dauerhaft bleiben.

Prüfe nach jedem neuen Projekt, welche Entscheidung erneut getroffen wurde. Wird sie wiederholt, gehört sie wahrscheinlich in die gemeinsame Basis oder in eine Automatisierung. So bleibt die Landing Zone ein Arbeitsmodell, das mit den tatsächlichen Bedürfnissen wächst, statt eine Architektur zu werden, die sich selbst rechtfertigen muss.

Wenn ein neues Projekt schneller startet, weniger Abstimmungen benötigt und von Anfang an klar ist, wer verantwortlich ist, erfüllt die Landing Zone ihren Zweck.

Wie wachsen eure Azure-Projekte? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.