Struktur für skalierbare Azure-Umgebungen

Azure Landing Zone: Struktur für skalierbare Azure-Umgebungen

Mit Service Groups hat Microsoft kürzlich ein neues Feature eingeführt, um Azure Ressourcen flexibler zu organisieren. Es ist deshalb interessant, weil es ein bekanntes Problem adressiert: Die technische Hierarchie einer Azure-Umgebung bildet selten ab, wie Teams tatsächlich arbeiten. Service Groups lösen dieses Problem allerdings nur an der Oberfläche. Sie schaffen zusätzliche Sichten, ersetzen aber nicht die geplante Grundstruktur darunter.

Diese Grundstruktur ist die Azure Landing Zone. Sie entscheidet darüber, ob eine AzureUmgebung langfristig kontrollierbar bleibt. Dieser Beitrag ordnet Service Groups kurz ein und betrachtet anschließend die Landing Zone als das eigentliche Fundament.

Service Groups: nützlich, aber kein Ersatz für Struktur

Eine Service Group ist eine flexible Gruppierung von Azure-Ressourcen über die Grenzen der bestehenden Hierarchie hinweg. Sie kann Ressourcen, Resource Groups und Subscriptions zusammenfassen, ohne die vorhandene Struktur aus Management Groups, Subscriptions und Resource Groups zu verändern. Eine Ressource kann gleichzeitig zu mehreren Service Groups gehören, und eine Berechtigung auf einer Service Group gewährt keinen Zugriff auf die darunterliegenden Ressourcen.

Damit eignen sich Service Groups für Sichtbarkeit, Inventarisierung und personaspezifische Ansichten, etwa wenn ein Plattform-Team alle Netzwerkressourcen über mehrere Subscriptions hinweg an einer Stelle sehen möchte. Sie sind jedoch kein Governance-Werkzeug: Richtlinien und Berechtigungen werden nicht an die Mitglieder vererbt. Dafür bleiben Management Groups und Azure Policy zuständig. Service Groups befinden sich zudem aktuell in der öffentlichen Vorschau (Public Preview), was für den produktiven Einsatz zu berücksichtigen ist.

Kurz gesagt: Service Groups setzen sinnvoll auf einer geordneten Umgebung auf. Ohne diese Ordnung fügen sie einer unstrukturierten Umgebung lediglich eine weitere Ebene hinzu. Genau deshalb lohnt der Blick auf die Landing Zone.

Was ist eine Azure Landing Zone?

Viele Azure-Umgebungen entstehen nicht nach einem klaren Architekturplan, sondern wachsen über Jahre. Neue Ressourcen werden angelegt, weitere Subscriptions kommen hinzu, Teams erhalten Berechtigungen, Policies werden punktuell ergänzt und Kostenstellen werden nachträglich zugeordnet. Das funktioniert eine Zeit lang. Problematisch wird es, wenn nicht mehr eindeutig erkennbar ist, welche Workloads zu welchem Bereich gehören, wer Zugriff auf welche Ressourcen hat, welche Richtlinien gelten und wie Kosten sauber ausgewertet werden können.

Genau hier setzt eine Azure Landing Zone an. Sie ist, auf Deutsch auch Azure-Zielzone genannt, die geplante Grundstruktur einer Azure-Umgebung. Microsoft beschreibt sie im Cloud Adoption Framework als standardisierten Ansatz, um Azure konsistent, sicher und skalierbar aufzubauen. Eine Landing Zone ist dabei kein einzelner Dienst, sondern ein Architekturkonzept.

^{Abbildung: Zentrale Architektur- und Governance-Bereiche einer Azure Landing Zone. Quelle: Microsoft Learn, Cloud Adoption Framework for Azure.}

Sie legt fest, wie zentrale Bestandteile der Umgebung aufgebaut werden:

• Management Groups und Subscriptions

• Netzwerktopologie

• Identität und Zugriff

• Azure Policy

• Logging und Monitoring

• Namenskonventionen

• Tags für Kosten und Betrieb

• Sicherheits- und Compliance-Vorgaben

Die Landing Zone ist damit das Fundament, auf dem spätere Workloads betrieben werden und auf dem Werkzeuge wie Service Groups erst sinnvoll aufsetzen.

Warum die frühe Strukturentscheidung wichtig ist

Viele spätere Betriebsprobleme entstehen nicht durch einzelne technische Fehler, sondern weil zentrale Strukturentscheidungen nie getroffen wurden. Typische Beispiele:

• Subscriptions wurden ohne einheitliches Modell erstellt.

• Ressourcen haben keine konsistente Namenskonvention.

• Tags fehlen oder werden uneinheitlich gepflegt.

• Berechtigungen wurden direkt auf einzelne Ressourcen vergeben.

• Richtlinien werden nur manuell kontrolliert.

• Netzwerkbereiche sind historisch gewachsen.

• Kosten lassen sich nicht eindeutig Teams, Projekten oder Kunden zuordnen.

Je länger eine Azure-Umgebung ohne klare Struktur wächst, desto schwieriger wird eine spätere Korrektur. Eine Landing Zone reduziert diesen Aufwand, weil grundlegende Regeln vorab definiert und automatisch auf neue Bereiche angewendet werden.

Management Groups und Subscriptions als organisatorisches Rückgrat

Ein zentraler Bestandteil einer Landing Zone ist die Struktur aus Management Groups und Subscriptions. Management Groups organisieren Subscriptions logisch und erlauben es, Governance-Vorgaben über mehrere Subscriptions hinweg anzuwenden. Richtlinien, Sicherheitsanforderungen und organisatorische Vorgaben lassen sich so auf einer höheren Ebene definieren.

Subscriptions sollten nicht zufällig entstehen, sondern bewusst nach Zweck, Verantwortung und Betriebsmodell getrennt werden. Häufige Trennungen sind zum Beispiel:

• Plattform- oder Connectivity-Subscription

• Management- oder Monitoring-Subscription

• Security-Subscription

• Workload-Subscriptions

• Sandbox- oder Testbereiche

Der Vorteil liegt nicht nur in der Übersicht. Eine saubere Subscription-Struktur erleichtert auch Kostenkontrolle, Zugriffskonzepte, Sicherheitsgrenzen und spätere Skalierung.

Azure Policy: Richtlinien automatisch durchsetzen

Eine Landing Zone wird erst dann wirksam, wenn Regeln nicht nur dokumentiert, sondern technisch durchgesetzt werden. Dafür ist Azure Policy relevant. Damit lassen sich organisatorische Standards und Compliance-Anforderungen automatisch auf Azure-Ressourcen anwenden, zum Beispiel:

• nur bestimmte Azure-Regionen erlauben

• verpflichtende Tags erzwingen

• nicht erlaubte Ressourcentypen blockieren

• Diagnoseeinstellungen voraussetzen

• Sicherheitskonfigurationen prüfen

• Abweichungen sichtbar machen

Der Unterschied zur manuellen Kontrolle ist wesentlich. Eine manuell gepflegte Richtlinie hängt davon ab, dass jemand sie kennt, prüft und konsequent anwendet. Eine technisch verankerte Policy wirkt automatisch innerhalb ihres Geltungsbereichs. Das ist besonders wichtig, wenn neue Subscriptions oder Workloads hinzukommen: Die Struktur sorgt dafür, dass bestimmte Vorgaben automatisch gelten.

RBAC braucht klare Scopes

Berechtigungen sind ein weiterer Bereich, in dem unstrukturierte Umgebungen schnell unübersichtlich werden. Mit Azure RBAC lassen sich Rollen auf verschiedenen Ebenen vergeben: Management Group, Subscription, Resource Group oder einzelne Ressource. Technisch ist das flexibel, ohne klares Modell führt diese Flexibilität aber oft zu schwer nachvollziehbaren Zugriffen.

Eine Landing Zone sollte deshalb festlegen:

• welche Rollen grundsätzlich verwendet werden

• auf welcher Ebene Rollen vergeben werden dürfen

• welche Teams Zugriff auf Plattformbereiche erhalten

• welche Berechtigungen Workload-Teams bekommen

• wie privilegierte Zugriffe kontrolliert werden

• wie temporäre Berechtigungen gehandhabt werden

Das Ziel ist nicht, jede Berechtigung maximal einzuschränken, sondern Zugriffe nachvollziehbar, prüfbar und betrieblich handhabbar zu machen.

Kostenkontrolle beginnt mit Struktur und Tags

Kostenprobleme in Azure sind selten nur ein Preisthema. Häufig fehlt die Zuordnung. Wenn Ressourcen nicht sauber benannt, gruppiert und getaggt sind, wird die Auswertung schwierig. Dann ist zwar sichtbar, dass Kosten entstanden sind, aber nicht, welchem Projekt, Team, Kunden oder Dienst sie zugeordnet werden müssen.

Microsoft empfiehlt im Cloud Adoption Framework eine klare Tagging-Strategie, weil Tags Kostenmanagement, Governance und Automatisierung unterstützen. Typische Tags sind zum Beispiel owner, cost-center, environment, workload, application, business-unit, data-classification und criticality. Wichtig ist, dass Tags nicht nur empfohlen, sondern technisch eingefordert werden. Auch hier hilft Azure Policy, fehlende Tags zu erkennen oder bestimmte Tags verpflichtend zu machen.

Netzwerk und Betrieb von Anfang an einplanen

Eine Landing Zone umfasst auch Netzwerk- und Betriebsentscheidungen. Dazu gehören beispielsweise Hub-and-Spoke-Modelle, Virtual WAN, zentrale Firewalls, DNS, private Endpunkte, Logging, Monitoring und Sicherheitsdienste. Microsoft beschreibt diese Themen in den Landing Zone Design Areas, die helfen, wichtige Entscheidungen vor der Umsetzung strukturiert zu betrachten.

Für den Betrieb ist das entscheidend. Eine Umgebung lässt sich nur dann zuverlässig betreiben, wenn Monitoring, Protokollierung, Sicherheitsmeldungen und Verantwortlichkeiten von Anfang an eingeplant sind. Werden diese Themen erst später ergänzt, entstehen oft Lücken in Transparenz, Sicherheit und Nachvollziehbarkeit.

Bestehende Umgebungen: Landing Zone nachträglich einführen

Nicht jede Organisation startet auf der grünen Wiese. Viele Unternehmen haben bereits produktive Azure-Umgebungen, bevor das Thema Landing Zone sauber betrachtet wird. In diesem Fall geht es nicht darum, alles neu aufzubauen, sondern um eine strukturierte Bestandsaufnahme:

1. Welche Management Groups und Subscriptions existieren?

2. Welche Ressourcen laufen in welchen Bereichen?

3. Welche Rollen und Berechtigungen sind vergeben?

4. Welche Policies sind aktiv?

5. Welche Tags werden genutzt?

6. Welche Kostenstellen sind nachvollziehbar?

7. Welche Netzwerkpfade bestehen?

8. Welche Logs und Sicherheitsdaten werden zentral erfasst?

Aus dieser Analyse lässt sich ableiten, welche Bereiche in eine Landing-Zone-Struktur überführt werden können und wo zuerst technische oder organisatorische Risiken reduziert werden müssen. Service Groups können in diesem Zuge helfen, bestehende Ressourcen über Subscription-Grenzen hinweg sichtbar zu machen, ohne sofort in die Hierarchie einzugreifen.

Praktische Prüffragen für die eigene Azure-Umgebung

Eine schnelle Einschätzung ist mit wenigen Fragen möglich:

• Gibt es eine dokumentierte Management-Group-Struktur?

• Werden neue Subscriptions nach einem festen Modell erstellt?

• Gelten zentrale Azure Policies automatisch?

• Sind Pflicht-Tags technisch erzwungen?

• Können Kosten eindeutig Workloads oder Verantwortlichen zugeordnet werden?

• Sind privilegierte Berechtigungen nachvollziehbar?

• Gibt es getrennte Bereiche für Plattform, Security, Connectivity und Workloads?

• Werden Logs und Sicherheitsdaten zentral gesammelt?

• Ist klar, welche Teams für welche Azure-Bereiche verantwortlich sind?

• Wird die Struktur regelmäßig überprüft?

Wenn mehrere dieser Fragen nicht eindeutig beantwortet werden können, ist die Azure Umgebung wahrscheinlich stärker gewachsen als geplant.

Fazit

Eine Azure Landing Zone ist kein zusätzlicher Verwaltungsaufwand, sondern die Grundlage dafür, dass Azure langfristig kontrollierbar bleibt. Sie sorgt dafür, dass Management Groups, Subscriptions, Policies, Berechtigungen, Netzwerk, Tags und Betriebsanforderungen nicht zufällig entstehen. Dadurch werden spätere Entscheidungen einfacher: neue Workloads lassen sich schneller integrieren, Richtlinien wirken konsistenter, Kosten werden nachvollziehbarer und Zugriffe bleiben prüfbar.

Service Groups sind in diesem Bild eine sinnvolle Ergänzung. Sie schaffen flexible Sichten über die Governance-Struktur hinweg, sobald das Fundament steht. Die wichtigere Frage bleibt aber die nach der Grundstruktur: nicht, ob eine Azure-Umgebung funktioniert, sondern ob sie kontrollierbar bleibt, wenn sie weiter wächst. Eine Landing Zone ist der Punkt, an dem diese Kontrolle bewusst geplant wird