AWS Landing Zone Setup mit Terraform: Aufbau, Security & Beratung

Warum so viele AWS-Umgebungen auf wackligem Grund stehen

Die meisten AWS-Umgebungen, die wir uns ansehen, haben ein gemeinsames Muster: Sie sind gewachsen, nicht geplant. Irgendwann hat jemand einen AWS-Account eröffnet, ein paar EC2-Instanzen gestartet, und dann ging es los. Drei Jahre später gibt es 15 Accounts ohne klare Struktur, Sicherheits-Policies, die niemand mehr versteht, und ein Netzwerk, das sich niemand mehr vollständig erklären kann.

Das ist keine Ausnahme. Das ist der Normalfall.

Wenn dann die Frage nach einer AWS Landing Zone auf den Tisch kommt, passiert eines von zwei Dingen: Entweder wird sie als Großprojekt behandelt, das ein halbes Jahr dauert und nie fertig wird. Oder sie wird schnell "irgendwie" aufgesetzt, weil der Druck hoch ist — und dann steht da eine Struktur, die auf dem Papier gut aussieht, aber in der Praxis niemand wirklich nutzt.

Terraform vor PowerPoint – das ist keine Floskel, das ist Erfahrung aus zu vielen AWS-Projekten, bei denen wir im zweiten Jahr aufgeräumt haben, was im ersten Jahr hätte vermieden werden können. Dieser Artikel erklärt, was eine AWS Landing Zone tatsächlich ist, was drin sein muss, was häufig schiefläuft — und wann man sich AWS Beratung holen sollte.

Was eine AWS Landing Zone wirklich ist

Eine Landing Zone ist kein AWS-Produkt. Es ist eine Architekturentscheidung.

Konkret: Eine AWS Landing Zone ist eine vorkonfigurierte, skalierbare Multi-Account-Umgebung, die als gesichertes Fundament für alle weiteren Workloads dient. Sie legt fest, wie Accounts strukturiert sind, wie Zugriffe geregelt werden, wie Netzwerke aufgebaut sind und welche Sicherheitsstandards für alle Accounts gelten — bevor der erste produktive Workload läuft.

AWS bietet mit Control Tower einen Managed Service an, der Landing-Zone-Konzepte vereinfacht und automatisiert. Das ist ein guter Ausgangspunkt. Aber Control Tower ist nicht die Landing Zone selbst — es ist ein Werkzeug, das dabei hilft, die Landing Zone aufzubauen und zu verwalten. Eine Landing Zone, die nur "Control Tower aktiviert" bedeutet, ohne dass jemand die konkrete Struktur dahinter durchdacht hat, ist keine Landing Zone. Es ist ein leeres Framework.

Was eine Landing Zone leisten soll:

• Governance von Anfang an: Wer darf was, auf welchen Accounts, unter welchen Bedingungen.
• Sicherheitsbaseline: Alle Accounts folgen denselben Mindeststandards — Logging, Monitoring, Verschlüsselung.
• Netzwerkarchitektur: Wie kommunizieren Workloads miteinander und mit der Außenwelt?
• Automatisierter Account-Lifecycle: Neue Accounts können konsistent und schnell bereitgestellt werden.
• Compliance-Readiness: Die Struktur macht Audits möglich, statt sie zu behindern.

Kurz gesagt: Eine Landing Zone ist die Infrastruktur, die dafür sorgt, dass alles, was danach kommt, sicher, wiederholbar und kontrollierbar bleibt.

AWS Landing Zone Setup: Was rein muss

Account-Struktur mit AWS Organizations

Alles beginnt mit einer durchdachten Account-Hierarchie in AWS Organizations. Einzelne AWS-Accounts sind die Sicherheitsgrenze in AWS — nicht IAM-Policies, nicht VPCs. Wer Workloads in einem Account betreibt, der aus Sicherheitssicht nicht isoliert ist, hat ein strukturelles Problem.

Eine typische Struktur sieht so aus:

• Root Management Account: Nur für Organizations-Verwaltung, keine Workloads.
• Security Account: Zentrales Security Tooling — AWS Security Hub, GuardDuty, CloudTrail aggregiert.
• Audit Account: Read-Only-Zugriff für interne und externe Prüfer. Bei Control Tower ein Pflicht-Bestandteil der Landing Zone — enthält vorkonfigurierte Rollen für AWS Security Audit und AWS Support. Wer Control Tower nutzt, bekommt ihn automatisch; wer ihn nicht explizit plant, baut nachher dran vorbei.
• Log Archive Account: Unveränderliche, zentralisierte Logs für alle Accounts.
• Shared Services Account: Netzwerk-Services, Transit Gateway, interne Tools.
• Workload Accounts (Dev / Staging / Prod): Strikt getrennt — ein Sicherheitsvorfall in Dev gefährdet nicht Prod.
• Sandbox Accounts: Für Experimente und Tests, mit klaren Kostengrenzen.

Diese Struktur klingt nach Overhead. Sie ist das Gegenteil davon. Wer jetzt in die Trennung investiert, vermeidet später teure Aufräumarbeiten. In Terraform sieht die Organizations- und OU-Grundstruktur so aus:

# organizations.tf
resource "aws_organizations_organization" "root" {
  aws_service_access_principals = [
    "cloudtrail.amazonaws.com",
    "config.amazonaws.com",
    "guardduty.amazonaws.com",
    "securityhub.amazonaws.com",
    "sso.amazonaws.com",
  ]
  feature_set = "ALL"
}

resource "aws_organizations_organizational_unit" "security" {
  name      = "Security"
  parent_id = aws_organizations_organization.root.roots[0].id
}

resource "aws_organizations_organizational_unit" "workloads" {
  name      = "Workloads"
  parent_id = aws_organizations_organization.root.roots[0].id
}

resource "aws_organizations_organizational_unit" "workloads_prod" {
  name      = "Production"
  parent_id = aws_organizations_organizational_unit.workloads.id
}

resource "aws_organizations_organizational_unit" "workloads_nonprod" {
  name      = "Non-Production"
  parent_id = aws_organizations_organizational_unit.workloads.id
}

Service Control Policies (SCPs)

SCPs sind Guardrails auf Organizations-Ebene. Sie legen fest, was in bestimmten Account-Gruppen (OUs) erlaubt oder verboten ist — unabhängig davon, welche IAM-Policies einzelne Nutzer haben. SCPs übertrumpfen alles.

Typische SCPs in einer sauberen Landing Zone:

• Regionen einschränken: Nur eu-central-1 und eu-west-1 erlaubt — kein Versehens-Deployment in us-east-1.
• Gefährliche Aktionen sperren: s3:DeleteBucket, cloudtrail:StopLogging, organizations:LeaveOrganization sind in Workload-Accounts gesperrt.
• Root-User-Aktionen einschränken: Root darf keine programmatischen Aktionen ausführen.
• Tagging erzwingen: Keine Ressource ohne Pflicht-Tags — die Grundlage für Cost Allocation und Security-Audits.

SCPs schreiben sich schnell. Sie richtig zu schreiben — so dass sie schützen ohne operativen Betrieb zu blockieren — ist die eigentliche Aufgabe:

# scp-deny-root.tf
resource "aws_organizations_policy" "deny_root_access" {
  name        = "DenyRootAccountAccess"
  description = "Verhindert Nutzung des Root-Accounts außer im Management Account"
  type        = "SERVICE_CONTROL_POLICY"

  content = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid      = "DenyRootAccess"
        Effect   = "Deny"
        Action   = ["*"]
        Resource = ["*"]
        Condition = {
          StringLike = {
            "aws:PrincipalArn" = ["arn:aws:iam::*:root"]
          }
        }
      }
    ]
  })
}

resource "aws_organizations_policy" "deny_regions" {
  name        = "DenyNonEURegions"
  description = "Erlaubt nur EU-Regionen – für DSGVO-Compliance"
  type        = "SERVICE_CONTROL_POLICY"

  content = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "DenyNonEURegions"
        Effect = "Deny"
        NotAction = [
          "iam:*", "organizations:*", "route53:*",
          "budgets:*", "sts:*", "support:*"
        ]
        Resource = ["*"]
        Condition = {
          StringNotLike = {
            "aws:RequestedRegion" = [
              "eu-central-1", "eu-west-1", "eu-west-2", "eu-north-1"
            ]
          }
        }
      }
    ]
  })
}

AWS Control Tower

Control Tower ist das Steuerungszentrum der Landing Zone. Es vereinfacht die Account-Erstellung über Account Factory, stellt vorkonfigurierte Guardrails bereit und gibt eine zentrale Sicht auf den Compliance-Status aller Accounts.

Was Control Tower abnimmt: Account-Baseline-Konfiguration, CloudTrail-Setup, Config-Aktivierung, initiale IAM-Rollen.

Was Control Tower nicht abnimmt: Das Nachdenken über die eigene Account-Struktur, die individuellen SCPs, das Netzwerkdesign und die Integration in bestehende Systeme. Für Teams mit Compliance-Anforderungen, bestehenden Terraform-Workflows oder spezifischen Netzwerk-Topologien ist eine Terraform-basierte Landing Zone oft die bessere Wahl — weil sie auditierbar bleibt und nicht von AWS-Produktentscheidungen abhängt.

Netzwerkarchitektur

Netzwerke sind oft die kritischste und am häufigsten unterschätzte Komponente. In einer Landing Zone wird das Fundament gelegt — und Fehler hier lassen sich später kaum ohne Downtime korrigieren.

• Hub-Spoke-Architektur: Ein zentrales Shared Services VPC als Hub, Workload-VPCs als Spokes. Kommunikation läuft über das Hub — nicht direkt zwischen Spokes.
• AWS Transit Gateway: Verbindet VPCs und On-Premises-Netzwerke skalierbar. Wer Transit Gateway nicht von Anfang an plant, baut es später unter Betrieb um.
• Private Endpoints: Für S3, Secrets Manager, ECR und andere AWS-Services — kein Traffic über das öffentliche Internet, auch wenn er intern ist.
• Egress Control: Ausgehender Traffic läuft über zentrale NAT Gateways im Hub — nicht aus jedem Workload-Account separat. Das spart Kosten und ermöglicht zentrale Filterung.

Das empfohlene Hub-and-Spoke-Muster mit AWS Transit Gateway in Terraform:

# transit-gateway.tf
resource "aws_ec2_transit_gateway" "main" {
  description                     = "Zentrales Transit Gateway"
  amazon_side_asn                 = 64512
  auto_accept_shared_attachments  = "disable"
  default_route_table_association = "disable"
  default_route_table_propagation = "disable"

  tags = {
    Name      = "org-transit-gateway"
    ManagedBy = "terraform"
  }
}

# RAM-Share: Transit Gateway für Workload-Accounts verfügbar machen
resource "aws_ram_resource_share" "transit_gateway" {
  name                      = "transit-gateway-share"
  allow_external_principals = false
}

resource "aws_ram_resource_association" "transit_gateway" {
  resource_arn       = aws_ec2_transit_gateway.main.arn
  resource_share_arn = aws_ram_resource_share.transit_gateway.arn
}

Security Baseline

Jeder Account bekommt ab dem ersten Tag die gleiche Sicherheitsgrundlage:

• AWS CloudTrail: API-Aktivitäten werden in allen Accounts geloggt, Logs laufen unveränderlich in den zentralen Log Archive Account.
• AWS Config: Konfigurationsänderungen werden aufgezeichnet — die Basis für Compliance-Audits und Drift-Detection.
• AWS Security Hub: Aggregiert Findings aus GuardDuty, Macie, Inspector und anderen Services. Eine zentrale Ansicht für alle Sicherheitsmeldungen.
• Amazon GuardDuty: Threat Detection in allen Accounts. Die Kosten hängen von Umgebungsgröße und aktivierten Features ab — die Foundational Threat Detection ist vergleichsweise günstig, aber wer EKS Audit Logs, S3 Protection oder Lambda Protection aktiviert, multipliziert die Kosten abhängig vom Traffic-Volumen. Das im Kostenmodell vorher einkalkulieren, nicht nachher.
• IAM Access Analyzer: Findet ungewollte externe Zugriffe auf Ressourcen — ein häufig übersehenes Tool mit hohem Nutzen.

Aktiviert wird das organisationsweit via Terraform und delegierte Administration:

# security-baseline.tf

# GuardDuty – delegierter Administrator im Security Account
resource "aws_guardduty_organization_admin_account" "security" {
  admin_account_id = var.security_account_id
}

# Security Hub – automatisch für neue Accounts
resource "aws_securityhub_organization_configuration" "main" {
  auto_enable           = true
  auto_enable_standards = "NONE"
}

# CloudTrail – organisation-weit, alle Regionen
resource "aws_cloudtrail" "organization" {
  name                          = "org-cloudtrail"
  s3_bucket_name                = aws_s3_bucket.log_archive.id
  is_organization_trail         = true
  enable_log_file_validation    = true
  include_global_service_events = true
  is_multi_region_trail         = true

  tags = {
    Environment = "management"
    ManagedBy   = "terraform"
  }
}

CI/CD-Integration

Eine Landing Zone, die nur manuell bedienbar ist, ist keine Landing Zone — es ist ein Dokument. Der Account-Lifecycle — Erstellung, Konfiguration, Updates — muss automatisiert sein. Das bedeutet: Die gesamte Landing-Zone-Konfiguration lebt in Git. Änderungen an SCPs, Netzwerkkonfiguration oder Account-Baselines werden über Pipelines ausgerollt, nicht per Klick in der Konsole. Auch der Terraform-State gehört dabei sauber getrennt — in den Management Account, in ein S3-Bucket mit Versioning und DynamoDB-Lock, nicht in einen Workload-Account.

Ein Hinweis zur Account-Provisionierung: Das ist ein eigenes Kapitel. Die Community ist gespalten — Control Tower Account Factory (mit Account Factory for Terraform, AFT) einerseits, reine Terraform-Lösungen via aws_organizations_account andererseits. Beide Ansätze haben Trade-offs bei Lifecycle-Management, State-Verwaltung und Abhängigkeiten vom Control Tower. Es gibt hier keine universell richtige Antwort — die Entscheidung hängt vom Team, der bestehenden Toolchain und den Compliance-Anforderungen ab. Wichtig ist, dass die Entscheidung bewusst getroffen wird, nicht als Nebensache.

Was häufig schiefläuft — und was es kostet

Fehler 1: Alles in einem Account

Klassiker. Spart anfangs Zeit, kostet später Nerven. Wenn Dev und Prod im selben Account laufen, ist ein fehlerhafter IAM-Policy-Bereich, ein Terraform-Fehler oder ein kompromittierter CI/CD-Key ein Produktionsvorfall. Wir haben Umgebungen gesehen, wo ein Entwickler versehentlich eine Produktions-Datenbank gelöscht hat — weil die Zugriffsstruktur schlicht nicht getrennt war. Der Umbau auf eine saubere Account-Struktur nachträglich ist möglich, aber aufwendig: Netzwerke neu bauen, Ressourcen migrieren, IAM-Strukturen komplett überarbeiten. Das kostet Wochen.

Fehler 2: Netzwerkarchitektur als Nachgedanke

Wir sehen regelmäßig Umgebungen mit VPCs, die sich gegenseitig über VPC Peering verbinden — in einer Mesh-Topologie, die mit jedem neuen Account quadratisch komplexer wird. Ab 8-10 Accounts ist das nicht mehr wartbar. Dann kommt Transit Gateway als Notlösung — und der Umbau passiert unter laufendem Betrieb. Der richtige Zeitpunkt für Transit Gateway ist bevor der erste Workload-Account live geht, nicht danach.

Fehler 3: SCPs zu spät oder zu ungenau

Entweder kommen SCPs gar nicht, weil "das regeln wir später" — und dann passiert es nie. Oder SCPs werden so restriktiv eingestellt, dass reguläre Operationen blockiert werden. Wir haben Umgebungen gesehen, wo ein zu restriktiver SCP dazu geführt hat, dass ein kritisches Update in Prod nicht ausgerollt werden konnte, weil die Service-Rolle gesperrt war. Gute SCPs brauchen Tests. Gegen reale Workloads. Nicht nur auf dem Papier.

Fehler 4: Logging als Checkbox

Klassische Lücke, die in einer soliden AWS Landing Zone Beratung als erstes auffällt. CloudTrail aktivieren, Haken setzen, fertig. Aber wo landen die Logs? Wie lange werden sie aufbewahrt? Wer hat Zugriff? Können sie verändert oder gelöscht werden? Logs, die nur im jeweiligen Workload-Account liegen, sind in einem Sicherheitsvorfall oft nicht mehr vertrauenswürdig — ein Angreifer mit Account-Level-Zugriff kann sie manipulieren. Unveränderliche, zentralisierte Logs in einem separaten Account sind kein Overkill, sondern Voraussetzung für jeden ernsthaften Sicherheits-Audit.

Fehler 5: Keine Automatisierung

Eine Landing Zone, die zu 80% per Klick in der Konsole konfiguriert wurde, ist in sechs Monaten nicht mehr reproduzierbar. Kein Mensch erinnert sich an alle Einstellungen. Und wenn jemand einen neuen Account braucht, dauert es wieder Tage statt Minuten. Spätestens wenn der erste Workload in die Landing Zone kommt und die Netzwerkkonfiguration nicht stimmt, wird an einer manuell konfigurierten Umgebung herumgedoktert — ohne dokumentierten Ausgangszustand.

Wann man es selbst schafft — und wann nicht

Selbst aufsetzen: Wann das funktioniert

Wer ein erfahrenes Cloud-Team hat, das bereits mit AWS Organizations und Terraform gearbeitet hat, kann eine Landing Zone selbst aufsetzen. AWS bietet mit Control Tower und dem Landing Zone Accelerator (LZA) auf GitHub solide Startpunkte. Die Voraussetzungen:

• Erfahrung mit Terraform (oder CloudFormation / CDK) in Multi-Account-Szenarien
• Verständnis von AWS-Netzwerkkonzepten: VPC, Transit Gateway, Routing, Private Endpoints
• Zeit für konzeptionelle Arbeit vor der Umsetzung — mindestens 2-3 Wochen für Design und Testing
• Bereitschaft, das Setup regelmäßig zu pflegen und mit AWS-Updates Schritt zu halten

Wenn das zutrifft: Loslegen. Die AWS-Dokumentation ist gut, der Landing Zone Accelerator eine solide Referenz.

Wann man Unterstützung braucht

In den meisten Fällen, die wir sehen, fehlt eine oder mehrere dieser Voraussetzungen:

• Das Cloud-Team hat AWS-Erfahrung, aber keine Multi-Account-Erfahrung. Beides ist nicht dasselbe.
• Es gibt Zeitdruck: Ein Workload soll in sechs Wochen live gehen, und die Landing Zone ist noch nicht da.
• Compliance-Anforderungen (ISO 27001, DSGVO, BSI) machen das Design komplexer.
• Das On-Premises-Netzwerk muss integriert werden (Site-to-Site VPN oder Direct Connect).
• Es gibt eine bestehende, gewachsene Umgebung, die migriert werden soll — nicht ein grünes Feld.

In diesen Situationen zahlt sich externe Unterstützung aus — nicht weil das Team es nicht könnte, sondern weil der Lernaufwand zu Verzögerungen führt, die teurer sind als die Beratung selbst.

Wie cloudpunks das macht

Wir setzen AWS Landing Zones embedded auf — nicht als Berater, die ein Konzept abliefern und gehen, sondern als Teil des Teams, das die Umgebung danach auch betreibt oder weiterentwickelt.

Terraform vor PowerPoint. Das bedeutet konkret: Wir liefern kein 50-seitiges Konzeptdokument, das sechs Monate in einer Schublade liegt. Wir liefern Terraform-Code, der getestet ist, in Git liegt und von eurem Team weiterentwickelt werden kann. Unser Vorgehen in vier Wochen:

• Woche 1 — Assessment und Design: Wir schauen uns an, was bereits da ist — bestehende Accounts, Workloads, Netzwerkkonfigurationen, IAM-Strukturen. Danach: Design der Account-Hierarchie, OUs, SCP-Strategie, Netzwerkarchitektur. Kein Overhead, keine Folien — ein klares technisches Konzept, das direkt in Umsetzung übergeht.
• Woche 2-3 — Umsetzung: Control Tower konfigurieren, Account Factory einrichten, Terraform-Module für die Landing-Zone-Baseline schreiben, Netzwerkarchitektur aufbauen, Security Baseline ausrollen, CI/CD-Integration.
• Woche 4 — Testing, Dokumentation, Übergabe: Wir testen die Struktur gegen reale Workloads, validieren SCPs, prüfen Netzwerkkonnektivität und durchlaufen einen simulierten Account-Onboarding-Prozess. Dann: Dokumentation und, wenn gewünscht, gemeinsame Arbeitssitzungen, damit das Team die Struktur versteht und selbst weiterentwickeln kann.

Was bleibt: Eine Landing Zone in Terraform, die in Git versioniert ist, die ihr versteht und selbst weiterentwickeln könnt. Kein Vendor-Lock-In in eine externe Dokumentation. Die Übergabe ist für uns nicht der Abschluss eines Projekts — wir begleiten Kunden typischerweise auch in den nachfolgenden Phasen: wenn die ersten Workloads in die Landing Zone ziehen, wenn neue Teams onboarden, wenn Compliance-Anforderungen schärfer werden. Die Landing Zone ist der erste Schritt einer langen Reise, nicht das Ziel.

Fazit: Fundament ist keine Option

Eine AWS Landing Zone ist kein Nice-to-Have für Unternehmen ab einer bestimmten Größe. Sie ist die Voraussetzung dafür, dass AWS-Infrastruktur skalierbar, sicher und kontrollierbar bleibt.

Wer heute ohne Landing Zone mit AWS-Workloads startet, baut auf wackligem Grund. Nicht weil AWS unsicher ist — sondern weil ohne klare Strukturen, Guardrails und automatisierte Baselines jedes Team seine eigene Interpretation von "guter Konfiguration" mitbringt. Das führt zu Inkonsistenz, Sicherheitslücken und einem Aufräum-Projekt, das deutlich teurer ist als das ursprüngliche Setup.

Die gute Nachricht: Mit dem richtigen Ansatz dauert ein solides Landing-Zone-Setup vier Wochen, nicht sechs Monate. Es braucht Erfahrung und Vorbereitung — aber keinen Großprojekt-Overhead.

Wenn ihr nicht sicher seid, ob eure aktuelle AWS-Umgebung auf einem soliden Fundament steht, oder wenn ihr eine neue Umgebung aufbauen wollt: Wir schauen uns eure AWS-Umgebung an und sagen euch ehrlich, wo ihr steht — ohne Verkaufsgespräch.