Azure Landing Zones mit Terraform: Einstieg, Struktur und Praxistipps

In meinen Azure-Kursen taucht die Frage nach Landing Zones fast immer dann auf, wenn Unternehmen von einzelnen Proof-of-Concept-Projekten in Richtung produktiver, governance-fähiger Cloud-Umgebungen wechseln wollen. Der Schmerz ist dabei überall gleich: Ressourcen landen irgendwo, Berechtigungen sind gewachsen statt geplant, und Netzwerksegmentierung war „für später“. Terraform bietet hier einen strukturierten Einstieg – vorausgesetzt, man versteht, was eine Landing Zone eigentlich ist und warum die Reihenfolge beim Aufbau entscheidend ist.

Was ist eine Azure Landing Zone – und was nicht?

Eine Azure Landing Zone ist kein einzelnes Azure-Produkt, das man aktiviert. Es ist ein Architekturmuster, das Microsoft im Cloud Adoption Framework (CAF) beschreibt: eine vorbereitete, wiederholbare Umgebung, in der Workloads sicher und compliant deployed werden können. Der Begriff umfasst dabei mehrere Ebenen gleichzeitig – Management Groups (Verwaltungsgruppen), Subscriptions (Abonnements), Richtlinien via Azure Policy, Netzwerktopologie und Identität.

Was viele Einsteiger verwechseln: Die Landing Zone ist nicht die Applikationsinfrastruktur selbst. Sie ist der Unterbau, auf dem Applikationsinfrastruktur später sicher und skalierbar betrieben werden kann. Das ist eine wichtige konzeptionelle Trennung, die ich in meinen Azure-Kursen immer wieder explizit herausarbeite – denn wer hier durcheinander kommt, baut zwangsläufig auf wackeligem Fundament.

Microsoft unterscheidet zwei grundlegende Implementierungsansätze:

Für diesen Artikel konzentriere ich mich auf den Terraform-Weg – konkret auf das offizielle Modul Azure/caf-enterprise-scale/azurerm.

Die Management Group-Hierarchie ist das Rückgrat jeder Azure Landing Zone – hier lassen sich Policies und RBAC-Rollen vererben.

Terraform-Struktur: Wie das offizielle ALZ-Modul funktioniert

Das offizielle Terraform-Modul für Azure Landing Zones – gepflegt unter github.com/Azure/terraform-azurerm-caf-enterprise-scale – abstrahiert erhebliche Komplexität. Es übernimmt das Anlegen der Management Group-Hierarchie, das Zuweisen von Azure Policies (inklusive der CAF-eigenen Policy Sets) sowie optionale Konnektivitäts- und Identity-Komponenten.

Ein minimaler Einstieg sieht in der main.tf so aus:

module "enterprise_scale" {
  source  = "Azure/caf-enterprise-scale/azurerm"
  version = "~> 5.0"

  providers = {
    azurerm              = azurerm
    azurerm.connectivity = azurerm.connectivity
    azurerm.management   = azurerm.management
  }

  root_parent_id = data.azurerm_client_config.current.tenant_id
  root_id        = "contoso"
  root_name      = "Contoso"

  deploy_management_resources    = true
  deploy_connectivity_resources  = true
  deploy_identity_resources      = true

  subscription_id_management    = var.management_subscription_id
  subscription_id_connectivity  = var.connectivity_subscription_id
  subscription_id_identity      = var.identity_subscription_id
}

Das Modul erwartet mindestens drei dedizierte Subscriptions: eine für Management (Log Analytics Workspace, Azure Monitor), eine für Connectivity (Hub-Netzwerk, Firewall, VPN/ExpressRoute) und eine für Identity (Domain Services oder Entra ID-Komponenten). Das klingt nach Overhead – ist aber bei näherer Betrachtung konsequente Trennung von Verantwortlichkeit und Abrechnungseinheit (Billing Boundary).

Merksatz: Jede dedizierte Subscription in einer Landing Zone ist gleichzeitig eine Billing Boundary (Abrechnungsgrenze) und eine Policy Boundary (Richtliniengrenze). Wer beide Grenzen in einer einzigen Subscription vermischt, verliert Kontrolle über beides.

Das Modul lässt sich über eine variables.tf und zugehörige JSON-/YAML-Dateien erweitern – zum Beispiel um eigene Azure Policy Definitionen oder um Anpassungen an der Management Group-Hierarchie. Für KMUs empfiehlt sich zunächst die Standardstruktur zu übernehmen und erst dann selektiv anzupassen.

Eine saubere Verzeichnisstruktur trennt Modulaufruf, Variablen und Landing-Zone-Anpassungen in eigenen Dateien.

Typische Stolperfallen beim ersten Rollout

Folgendes Problem aus der Praxis: Ein Kunde deployt das Modul zum ersten Mal und erhält nach terraform apply hunderte von Policy-Zuweisungen – viele davon im Modus DeployIfNotExists oder Modify. Das sorgt für Remediation Tasks (Nachbesserungsaufgaben), die im Hintergrund anlaufen und Ressourcen verändern, die der Kunde noch gar nicht vollständig kontrolliert. Die Reaktion: Panik, weil sich scheinbar „etwas selbst verändert“.

Die Lösung liegt im Verständnis des Policy Effect: Beim ersten Rollout empfiehlt es sich, zunächst nur mit Audit-Policies zu arbeiten und DeployIfNotExists-Zuweisungen erst nach vollständiger Inventarisierung zu aktivieren. Das offizielle Modul erlaubt das über den Parameter policy_effect_override in den Archetype Definitions.

Weitere häufige Probleme, die ich in Trainings und Kundenprojekten sehe:

Praxistipp: Führen Sie terraform plan nach dem ersten Modulaufruf immer in einer Nicht-Produktionsumgebung aus und werten Sie die Ausgabe vollständig aus – vor allem die Anzahl der Policy-Zuweisungen. Mehr als 200 geplante Ressourcen beim ersten Apply sind normal, sollten aber nicht blind bestätigt werden.

Praxisempfehlung: KMU-taugliche Minimalstruktur

Noch mal in Kürze – kurz, knapp und strukturiert, zum Abhaken: Für kleinere Unternehmen, die mit Azure Landing Zones starten, ohne sofort die volle Enterprise-Komplexität abzubilden, empfehle ich folgende Minimalstruktur:

• Eine Management Group-Hierarchie mit Root, einer „Landing Zones“-Gruppe und je einer Untergruppe für Produktion und Non-Produktion
• Zwei Subscriptions initial: eine für Plattformdienste (Management + Connectivity zusammengefasst), eine für die erste Applikation
• State-Verwaltung über Azure Storage Account mit aktiviertem Versioning und State-Locking via azurerm-Backend
• Nur Audit-Policies in der ersten Phase – kein DeployIfNotExists bis zur vollständigen Inventarisierung
• Git-Repository mit Branch-Schutz auf main, Pull-Request-basierter Pipeline via Azure DevOps oder GitHub Actions

Diese Struktur ist in meinen Azure-Kursen der empfohlene Startpunkt – sie lässt sich jederzeit zur vollständigen Enterprise-Scale-Topologie erweitern, ohne die Grundstruktur zu reißen. Wer direkt mit der maximalen Komplexität startet, verbringt mehr Zeit mit Verwaltung als mit produktiven Workloads.

Azure Landing Zones mit Terraform sind kein Einmalprojekt, sondern eine lebende Plattform. Versionierung, dokumentierter State und saubere Modulgrenzen sind keine optionalen Qualitätsmerkmale – sie sind die Voraussetzung dafür, dass das Fundament trägt, wenn die Anforderungen wachsen.