Grundlagen & Einstieg

Landing Zone aufbauen: das Fundament vor der ersten Migration

Eine Landing Zone ist keine Vorlage, die man einmal ausrollt, sondern der Satz an Entscheidungen zu Konten, Rechten, Netz und Richtlinien, den du danach nur noch schwer ändern kannst. Wer diese Entscheidungen vor der ersten Anwendung trifft, spart sich später den teuersten aller Umbauten. Als Code beschrieben bleibt sie reproduzierbar und in Prüfungen belegbar.

5 Kapitel mit allen Befehlen
Einsteigerin in die Cloud-Administration an zwei Monitoren mit Dashboards
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum nachträgliche Ordnung so teuer ist

Fast jede Cloud-Nutzung beginnt gleich: ein Konto oder ein Abonnement, ein paar Personen mit weitreichenden Rechten, ein erstes Projekt. Das funktioniert erstaunlich lange. Nach etwa achtzehn Monaten liegen dann fünfzig Ressourcengruppen nebeneinander, drei Netze überschneiden sich in den Adressbereichen, niemand kann sagen, wem welche Maschine gehört, und die monatliche Rechnung lässt sich keiner Kostenstelle zuordnen. Genau an diesem Punkt taucht der Begriff Landing Zone zum ersten Mal auf, und zwar später als nötig.

Der nachträgliche Umbau ist deshalb so teuer, weil die betroffenen Entscheidungen tief liegen. Ressourcen zwischen Konten oder Abonnements zu verschieben ändert Kennungen und bricht Verweise in Skripten, Pipelines und Überwachung. Überschneidende Adressbereiche verhindern jede spätere Kopplung der Netze, und eine Umnummerierung im laufenden Betrieb ist ein eigenes Projekt. Kennzeichnungen lassen sich zwar nachträglich setzen, sie reparieren aber keine einzige vergangene Rechnung. Jede dieser Korrekturen kostet ein Vielfaches der ursprünglichen Einrichtung.

Gleichzeitig ist eine Landing Zone kein Produkt, das man einschaltet. AWS Control Tower und die Landing-Zone-Vorlagen aus dem Cloud Adoption Framework nehmen viel Arbeit ab, aber die Entscheidungen bleiben im Haus: Wie werden Konten geschnitten, welche Namen gelten, welche Regionen sind erlaubt, wer darf Ausnahmen genehmigen und wie kommt ein neues Team an seine Umgebung. Diese Antworten sind der eigentliche Kern, die Werkzeuge setzen sie nur um.

Miniatur-Szene: Treppe aus drei Stufen hinauf zu einer schwebenden Cloud, Laptop und Wegweiser

Die Landing Zone in sechs Bausteinen

  1. 01 Organisationsstruktur aus Konten oder Abonnements
  2. 02 Zentrale Identität, Rechte ausschließlich über Gruppen
  3. 03 Leitplanken über Richtlinien und Dienststeuerung
  4. 04 Netzplan mit überschneidungsfreien Adressbereichen
  5. 05 Protokolle und Sicherheitsdaten in einem eigenen Konto
  6. 06 Alles als Code, versioniert und reproduzierbar
Was du mitnimmst

Sechs Bausteine, ohne die es keine Landing Zone ist

Die Begriffe unterscheiden sich zwischen AWS und Azure, die Entscheidungen sind dieselben. Fehlt einer dieser Bausteine, ist es eine Sammlung von Ressourcen und keine Landing Zone.

Struktur aus Konten und Abonnements

Die einzige Trennung, die wirklich hält, verläuft entlang von Konten in AWS und Abonnements in Azure. Rechte, Kontingente und Rechnungen folgen dieser Grenze automatisch. Ein Konto je Umgebung und Fachbereich ist der übliche Schnitt, darüber liegen Organisationseinheiten oder Verwaltungsgruppen als Träger der Richtlinien.

Identität zentral, Rechte über Gruppen

Anmeldungen laufen über einen zentralen Verzeichnisdienst, Rechte werden ausschließlich an Gruppen vergeben und nie an einzelne Personen. Dauerhafte Zugangsschlüssel gehören abgeschafft, Anmeldungen laufen über kurzlebige Sitzungen. Damit ist der Austritt eines Mitarbeiters ein Vorgang im Verzeichnis und keine Suche in zwanzig Konten.

Leitplanken als Richtlinien statt als Text im Wiki

Erlaubte Regionen, verbotene Dienste, Pflichtkennzeichnungen und Verschlüsselungsvorgaben gehören in Dienststeuerungsrichtlinien beziehungsweise Azure Policy. Eine Regel, die nur im Wiki steht, wird verletzt, ohne dass es jemand merkt. Eine Regel als Richtlinie greift ohne Freigabeschritt und liefert nebenbei den Nachweis für Prüfungen.

Netzplan mit überschneidungsfreien Adressbereichen

Vor dem ersten virtuellen Netz steht die Vergabe der Adressbereiche, abgestimmt mit dem Netzwerkteam im eigenen Rechenzentrum. Reserviere je Umgebung und Region einen Block, dokumentiere die Vergabe an einer Stelle und halte sie ein. Das ist die Entscheidung, die sich am schlechtesten korrigieren lässt.

Protokolle in einem eigenen Konto

Sicherheitsrelevante Protokolle gehören in ein Konto oder Abonnement, auf das die Workload-Teams keinen Schreibzugriff haben. Sonst kann jemand, der ein Konto übernommen hat, seine eigenen Spuren entfernen. Diese Trennung ist in Prüfungen nach NIS2 und BSI C5 ein regelmäßiger Prüfpunkt.

Alles als Code, mit einem Zustand je Umgebung

Struktur, Richtlinien, Netze und Rollen werden als Code beschrieben und versioniert. Nur so lässt sich die Landing Zone reproduzieren, in einer zweiten Region aufbauen und im Nachhinein belegen. Ein getrennter Zustand je Umgebung verhindert, dass ein Fehler in der Entwicklung die Produktion mitzieht.

Tutorial

Von der Kontenstruktur bis zur Leitplanke im Code

Eine Landing Zone ist keine Vorlage, sondern der Satz an Entscheidungen zu Konten, Rechten, Netz und Richtlinien, den du danach nur noch schwer änderst. Genau deshalb entstehen sie hier in der Reihenfolge, in der sie trägt: erst die Struktur aus Konten und Verwaltungsgruppen, dann die Leitplanken über Richtlinien, danach Netzplan und Protokollierung und zum Schluss die Beschreibung als Code. Die Beispiele zeigen AWS und Azure nebeneinander, weil die Begriffe verschieden heißen, die Entscheidungen aber dieselben sind.

01

Schritt 1: Die Struktur schneiden

Schneide entlang von Verantwortung und Umgebung, nicht entlang von Projekten. Projekte enden, Verantwortung bleibt.

Organisation und Struktur anlegen
# AWS: Organisation mit allen Funktionen, danach Organisationseinheiten
aws organizations create-organization --feature-set ALL
ROOT=$(aws organizations list-roots --query 'Roots[0].Id' --output text)

aws organizations create-organizational-unit --parent-id "$ROOT" --name Workloads
aws organizations create-organizational-unit --parent-id "$ROOT" --name Security
aws organizations create-organizational-unit --parent-id "$ROOT" --name Sandbox

# Azure: Verwaltungsgruppen unterhalb der Mandantenwurzel
az account management-group create --name mg-plattform --display-name "Plattform"
az account management-group create --name mg-workloads \
  --display-name "Workloads" --parent mg-plattform

az account management-group subscription add --name mg-workloads \
  --subscription "00000000-0000-0000-0000-000000000000"

Ein eigenes Konto oder Abonnement je Umgebung ist die einzige Trennung, die im Alltag wirklich hält. Rechte, Kontingente und Rechnungen folgen dieser Grenze automatisch, während eine Trennung über Ressourcengruppen oder Namenskonventionen immer nur so gut ist wie die Disziplin des Teams.

Wo die Grenze verläuft

Trennung nachAWSAzureWarum
UmgebungEigenes Konto je StufeEigenes Abonnement je StufeEin Fehler in der Entwicklung kann die Produktion nicht erreichen
FachbereichOrganisationseinheit je BereichVerwaltungsgruppe je BereichRichtlinien und Rechte lassen sich vererben statt einzeln zu pflegen
SicherheitEigenes Konto für Protokolle und WerkzeugeEigenes Abonnement für ProtokolleProtokolle bleiben lesbar, auch wenn ein Konto übernommen wurde
ExperimenteSandbox mit engem Budget und kurzer LebensdauerSandbox-Verwaltungsgruppe mit AusgabenwarnungAusprobieren bleibt möglich, ohne die Regeln der Produktion aufzuweichen
02

Schritt 2: Leitplanken setzen, die niemand umgehen kann

Regeln, die nur im Wiki stehen, werden verletzt, ohne dass es jemand merkt. Als Richtlinie greifen dieselben Regeln ohne Freigabeschritt.

AWS: Aktionen außerhalb der EU verweigern
cat > deny-non-eu.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "NotAction": [
        "iam:*", "sts:*", "organizations:*", "account:*",
        "support:*", "health:*", "budgets:*", "ce:*", "cur:*",
        "cloudfront:*", "route53:*", "waf:*", "shield:*"
      ],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": {
        "aws:RequestedRegion": ["eu-central-1", "eu-west-1"]
      }
    }
  }]
}
JSON

aws organizations create-policy --name DenyNonEU \
  --type SERVICE_CONTROL_POLICY --content file://deny-non-eu.json

aws organizations attach-policy --policy-id p-beispiel \
  --target-id ou-beispiel

Globale Dienste wie IAM, Organizations und CloudFront melden sich immer in us-east-1 an. Ohne die Ausnahme über NotAction sperrt die Richtlinie die Verwaltung des eigenen Kontos gleich mit aus. Hänge sie zuerst an die Sandbox-Organisationseinheit, nie direkt an die Wurzel. Wichtig: Auch Abrechnung und Kostenanalyse melden sich in us-east-1 an. Wer budgets und ce in der Ausnahmeliste vergisst, verliert nach dem Ausrollen den Blick auf die eigene Rechnung.

Azure: erlaubte Regionen als Richtlinie zuweisen
# Eingebaute Definition suchen, statt die Kennung zu raten
POLICY=$(az policy definition list \
  --query "[?displayName=='Allowed locations'].name | [0]" -o tsv)

az policy assignment create \
  --name nur-eu-regionen \
  --display-name "Nur Regionen in der EU" \
  --scope "/providers/Microsoft.Management/managementGroups/mg-workloads" \
  --policy "$POLICY" \
  --params '{"listOfAllowedLocations":{"value":["germanywestcentral","westeurope"]}}'

# Nach einigen Minuten die Konformität auswerten
az policy state summarize --management-group mg-workloads

Richtlinien greifen zuerst bei neuen Ressourcen. Bestehende Verstöße zeigt die Konformitätsauswertung nur an, entfernt werden sie nicht. Für Korrekturen brauchst du Richtlinien mit Korrekturaufgabe und eine verwaltete Identität mit den passenden Rechten, und beides gehört vorher in einer Sandbox getestet.

03

Schritt 3: Netzplan und Protokollierung

Adressbereiche und Protokollierung sind die beiden Bausteine, bei denen ein Fehler am spätesten auffällt und am teuersten zu beheben ist.

Adressbereiche vergeben und Protokolle zentral sammeln
# Azure: Nabe und Speiche, Adressräume überschneidungsfrei
az network vnet create -g rg-hub -n vnet-hub --address-prefixes 10.0.0.0/20
az network vnet create -g rg-prod -n vnet-prod --address-prefixes 10.1.0.0/16

az network vnet peering create -g rg-hub -n hub-zu-prod \
  --vnet-name vnet-hub \
  --remote-vnet "$(az network vnet show -g rg-prod -n vnet-prod --query id -o tsv)" \
  --allow-vnet-access --allow-forwarded-traffic

# AWS: organisationsweite Protokollierung in ein eigenes Konto
aws cloudtrail create-trail --name org-trail \
  --s3-bucket-name acme-org-trail-eu-central-1 \
  --is-organization-trail --is-multi-region-trail
aws cloudtrail start-logging --name org-trail

Der Adressplan ist die Entscheidung, die sich am schlechtesten korrigieren lässt. Überschneiden sich zwei Bereiche, ist keine Kopplung der Netze möglich, und eine Umnummerierung im laufenden Betrieb ist ein eigenes Projekt. Reserviere je Umgebung und Region einen Block und halte die Vergabe an einer Stelle fest, auf die auch das Netzwerkteam im eigenen Rechenzentrum schaut.

Die Anbindung an das eigene Rechenzentrum gehört in denselben Planungsschritt, weil sie den Adressplan mitbestimmt und oft lange Vorlaufzeiten hat. Die Optionen von VPN bis zur dedizierten Leitung stehen unter Rechenzentrum an die Cloud anbinden.

04

Schritt 4: Die Landing Zone als Code beschreiben

Von Hand geklickte Strukturen lassen sich weder reproduzieren noch prüfen. Ab hier gilt: Was nicht im Repository steht, existiert nicht.

terraform/landing-zone/main.tf
terraform {
  required_version = ">= 1.10"

  backend "s3" {
    bucket       = "acme-tfstate-eu-central-1"
    key          = "landing-zone/terraform.tfstate"
    region       = "eu-central-1"
    encrypt      = true
    use_lockfile = true
  }
}

provider "aws" {
  region = "eu-central-1"

  default_tags {
    tags = {
      kostenstelle  = var.kostenstelle
      umgebung      = var.umgebung
      verwaltet_von = "terraform"
    }
  }
}

module "organisation" {
  source                 = "./module/organisation"
  organisationseinheiten = ["Workloads", "Security", "Sandbox"]
}

default_tags im Anbieterblock ist der einfachste Weg, damit keine Ressource ohne Kennzeichnung entsteht. Für den Zustand gilt: eine Datei je Umgebung, verschlüsselt, versioniert und gesperrt. Seit Terraform 1.10 übernimmt use_lockfile die Sperre direkt im Bucket, eine zusätzliche DynamoDB-Tabelle ist dafür nicht mehr nötig.

Änderungen geplant ausrollen und zurückdrehen
terraform init
terraform plan -out=tfplan

# Billigste Prüfung überhaupt: entfernt der Lauf etwas?
terraform show -json tfplan \
  | jq '.resource_changes[] | select(.change.actions[] == "delete") | .address'

terraform apply tfplan

# Rückweg: nur den betroffenen Teil zurücknehmen
terraform plan -destroy -target=module.sandbox -out=rueckbau.tfplan
terraform apply rueckbau.tfplan

Der Filter auf delete zeigt vor dem Ausrollen, ob der Lauf etwas entfernt, das gar nicht entfernt werden sollte. In einer Landing Zone betrifft das schnell ein ganzes Konto, und ein geschlossenes Konto kommt nicht ohne Weiteres zurück. Lass diesen Befehl in der Pipeline laufen und brich ab, sobald er etwas ausgibt.

05

Schritt 5: Abnahme, bevor die erste Anwendung kommt

Diese sechs Punkte trennen eine Landing Zone, die trägt, von einer Sammlung gut gemeinter Vorlagen.

Die Landing Zone ist abnahmefähig, wenn

  • Ein neues Konto oder Abonnement entsteht über den definierten Weg in unter einem TagDauert es länger, bauen sich die Teams eigene Umgebungen an der Struktur vorbei. Genau diese Ausweichbewegung erzeugt die Unordnung, die die Landing Zone verhindern sollte.
  • Zwei Notfallkonten existieren, sind von Richtlinien ausgenommen und werden überwachtOhne diesen Ausweg sperrt die erste falsch gesetzte Richtlinie die gesamte Verwaltung aus. Der Herstellersupport braucht dafür Tage, in denen nichts mehr geändert werden kann.
  • Protokolle liegen in einem Konto, auf das die Workload-Teams keinen Schreibzugriff habenWer ein Konto übernimmt, entfernt sonst als Erstes seine Spuren. Getrennte Protokollhaltung ist in Prüfungen nach NIS2 und BSI C5 ein fester Prüfpunkt und lässt sich nicht rückwirkend herstellen.
  • Jede Ressource trägt Kostenstelle, Umgebung und EigentümerOhne diese drei Kennzeichnungen ist keine Rechnung zuzuordnen und keine verwaiste Ressource zu finden. Nachträglich gesetzte Kennzeichnungen reparieren keine einzige vergangene Abrechnung.
  • Der Adressplan ist dokumentiert und mit dem Netzwerkteam abgestimmtÜberschneidende Bereiche verhindern jede spätere Kopplung von Netzen und die Anbindung an das eigene Rechenzentrum. Die Korrektur bedeutet eine Umnummerierung im laufenden Betrieb.
  • Die gesamte Struktur lässt sich aus dem Code in einer leeren Umgebung neu erzeugenDas ist der einzige belastbare Nachweis, dass nichts von Hand geklickt wurde. Gleichzeitig ist es die Voraussetzung dafür, eine zweite Region oder eine Testumgebung ohne Handarbeit aufzubauen.

Steht das Fundament, folgt die Reihenfolge der Umzüge. Wie sich Anwendungen bewerten, bündeln und in Wellen migrieren lassen, steht unter Cloud-Migration planen. Wenn Nachweise gegenüber Kunden oder Aufsicht gefragt sind, lohnt ein Blick auf das BSI-C5-Testat, denn viele der dort geforderten Nachweise entstehen genau in dieser Aufbauphase fast nebenbei.

Gut zu wissen

Häufige Fragen zu Landing Zones und Cloud-Governance

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Was gehört mindestens in eine Landing Zone?
Sechs Bausteine: eine Struktur aus Konten oder Abonnements, zentrale Identität mit Rechten über Gruppen, Leitplanken als Richtlinien, ein Netzplan mit überschneidungsfreien Adressbereichen, getrennte Protokollhaltung in einem eigenen Konto und die Beschreibung des Ganzen als Code. Fehlt einer davon, ist es eine Sammlung von Ressourcen. Alles Weitere, etwa ein Servicekatalog oder automatisierte Kontobereitstellung, ist nützlich, aber nicht Voraussetzung für den Start.
Reicht AWS Control Tower oder die Azure-Landing-Zone-Vorlage aus?
Beide nehmen viel Arbeit ab und sind ein guter Ausgangspunkt, ersetzen aber die Entscheidungen nicht. Wie Konten geschnitten werden, welche Namen gelten, welche Regionen erlaubt sind, wer Ausnahmen genehmigt und wie ein Team an seine Umgebung kommt, entscheidet das eigene Haus. Rechne damit, dass die Werkzeuge etwa die Hälfte der Arbeit abnehmen und die andere Hälfte aus Abstimmung, Namenskonventionen und Anpassung an die eigenen Vorgaben besteht.
Ein Konto pro Team oder ein Konto pro Umgebung?
In der Praxis beides kombiniert: ein Konto je Team und Umgebung. Das klingt nach vielen Konten, ist aber genau der Punkt, denn Konten sind kostenlos und die Trennung ist die einzige, die zuverlässig hält. Ein Team mit Entwicklung, Test und Produktion bekommt also drei Konten, gebündelt unter einer Organisationseinheit oder Verwaltungsgruppe, an der die Richtlinien hängen. Die Grenze liegt eher bei der Verwaltbarkeit, und die verlangt Automatisierung der Kontobereitstellung.
Wie viele Pflichtkennzeichnungen sind sinnvoll?
Vier bis sechs, mehr wird nicht gepflegt. Bewährt haben sich Kostenstelle, Umgebung, Eigentümer und Anwendung, dazu bei Testumgebungen ein Ablaufdatum. Wichtig ist weniger die Auswahl als die Durchsetzung: Setze die Kennzeichnungen als Standardwerte im Code und erzwinge sie zusätzlich über eine Richtlinie, die fehlende Angaben ablehnt. Eine Kennzeichnung, die von Hand vergeben werden muss, fehlt nach drei Monaten bei einem Drittel der Ressourcen.
Können wir eine Landing Zone auch nachträglich einführen?
Ja, aber in Etappen und mit klarem Schnitt. Der übliche Weg: eine saubere Struktur neben dem Bestand aufbauen, alle neuen Anwendungen ausschließlich dort starten und den Bestand nach Aufwand und Nutzen nachziehen. Ein Umzug in einem Zug scheitert fast immer an Adressüberschneidungen und an Verweisen auf Kontokennungen. Rechne für den Bestand mit mehreren Quartalen und akzeptiere, dass einzelne Altsysteme dauerhaft außerhalb bleiben, solange sie klar abgegrenzt sind.

Zuletzt geprüft am 28. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Der Kurs hat sein Ziel erreicht. Der Trainer konnte die Inhalte gut rüberbringen und der Praxisanteil und die Übungsumgebung war sehr gut.
Rückmeldung aus dem Kurs „Terraform mit Azure – Der kompakte Praxiskurs für Ihren Cloud-Erfolg“
Super, komplett auf uns und unsere Bedürfnisse eingegangen. Der Tag hat uns viel geholfen und wir könnten das alles in unserem Arbeitsalltag nutzen.
Rückmeldung aus dem Kurs „DP-080 Training: Abfragen von Daten mit Microsoft Transact-SQL (DP-080T00)“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Fundament bauen, bevor die erste Anwendung umzieht

Eine Landing Zone entsteht an der Schnittstelle von Architektur und Automatisierung, und genau dort setzen unsere Kurse an. AZ-305 und Architecting on AWS liefern die Entwurfsseite, AWS Security Governance at Scale nimmt sich Leitplanken und Nachweise vor, und die beiden Terraform-Kurse zeigen, wie das Ergebnis reproduzierbar im Code landet. Alle Kurse gibt es als Präsenztermin und Live-Online, auf Wunsch auch als geschlossenes Team-Training entlang eurer eigenen Zielstruktur.