AWS-Landing-Zone-Diagramm: Multi-Account-Setup mit Organizations und Control Tower

Ein einziger AWS-Account für alles funktioniert, bis er es nicht mehr tut. Ein Testskript löscht einen Produktions-Bucket. Finance kann die Rechnung nicht nach Teams aufteilen. Ein Auditor fragt, wer die Audit-Logs ändern kann, und die ehrliche Antwort lautet „jeder mit Admin-Rechten“. Eine Landing Zone ist das Multi-Account-Fundament, das du legst, bevor Workloads ankommen: die Account-Struktur, Identität, Guardrails, Logging und das Netzwerk, die jeder neue Account erbt.

Dieser Beitrag geht ein Landing-Zone-Design anhand eines Diagramms durch: warum mehrere Accounts, die empfohlenen Organisationseinheiten, die Kern-Accounts, Guardrails mit Service-Kontrollrichtlinien (SCPs), Ressourcenkontrollrichtlinien (RCPs) und deklarativen Richtlinien, Identität, zentrales Logging und Security-Tooling, Netzwerk und wie du das Ganze mit Control Tower aufbaust, einschließlich der Änderungen in Landing Zone 4.0, oder mit Terraform.

Warum mehrere Accounts

Ein AWS-Account ist die stärkste Isolationsgrenze, die AWS bietet. IAM-Berechtigungen, Service-Kontingente, Kosten und die meisten Ausfälle enden an seiner Grenze. Getrennte Accounts bringen dir:

• Begrenzten Schadensradius. Ein Fehler oder kompromittierte Zugangsdaten in einer Sandbox können die Produktion nicht berühren.
• Klare Zuständigkeit und Abrechnung pro Team, Anwendung oder Umgebung.
• Einfachere Berechtigungen. Statt eines Accounts voller Bedingungen auf Tags bekommt jeder Account genau den Zugriff, den sein Team braucht.
• Unabhängige Kontingente, damit der Lasttest eines Teams nicht die Limits eines anderen aufbraucht.

Der Preis ist Koordination: Identität, Logging, Guardrails und Netzwerk müssen über Dutzende Accounts hinweg funktionieren. Genau diese Koordination liefert eine Landing Zone.

Die Struktur: Organisationseinheiten

AWS Organizations gruppiert Accounts in Organisationseinheiten (OUs), und Richtlinien an einer OU gelten für jeden Account darunter. Das AWS-Whitepaper zur Organisation deiner Umgebung empfiehlt einen Satz von OUs als Ausgangspunkt:

Teile Workloads früh in die Unter-OUs Prod und Non-prod. Die Guardrails unterscheiden sich, und Accounts später umzuziehen ist mühsam. Füge eine Suspended-OU mit einer Deny-all-Richtlinie für Accounts hinzu, die auf ihre Schließung warten.

Der Management-Account

Der Management-Account besitzt die Organisation, die konsolidierte Abrechnung und Control Tower. Halte Workloads aus ihm heraus, aus einem entscheidenden Grund: SCPs wirken nicht auf Benutzer oder Rollen im Management-Account, wie die Organizations-Dokumentation festhält. Nichts, was du dort bereitstellst, wird durch deine Guardrails eingeschränkt, also gib ihm so wenige Benutzer und Ressourcen wie möglich.

Kern-Accounts

• Log Archive. Empfängt den CloudTrail-Trail der Organisation und die AWS-Config-Historie in S3. Fast niemand bekommt Schreib- oder Löschzugriff; erwäge S3 Object Lock, damit nicht einmal Administratoren Logs verändern können.
• Security Tooling, auch Audit genannt. Der delegierte Administrator für GuardDuty, Security Hub, IAM Access Analyzer und den AWS-Config-Aggregator, damit das Security-Team jeden Account von einer Stelle aus sieht, ohne Zugriff auf den Management-Account.
• Network. Besitzt das Transit Gateway, private Verbindungen zu Rechenzentren, DNS-Resolver und das IP-Adressmanagement und teilt sie über AWS Resource Access Manager mit den Workload-Accounts.
• Shared Services. CI/CD, Artefakt-Repositorys und andere Tools, die viele Teams nutzen.

Guardrails: SCPs, RCPs und deklarative Richtlinien

Organizations bietet mehrere Richtlinientypen, und sie beantworten unterschiedliche Fragen:

Richtlinien schränken nur ein; sie gewähren nie Berechtigungen. Starte mit einer kurzen Liste wertvoller Guardrails:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "ProtectCloudTrail",
      "Effect": "Deny",
      "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail", "cloudtrail:UpdateTrail"],
      "Resource": "*"
    }
  ]
}

Regionsbeschränkungen sind beliebt und leicht falsch zu machen, weil globale Services wie IAM erlaubt bleiben müssen. Teste jede neue Richtlinie auf einer Staging-OU mit einem repräsentativen Account, bevor du sie an Workloads hängst.

Control Tower verpackt Guardrails als Controls in drei Arten: präventive Controls, umgesetzt mit SCPs und RCPs, detektive Controls, umgesetzt mit AWS-Config-Regeln, und proaktive Controls, die Ressourcen prüfen, bevor CloudFormation sie anlegt.

Identität

Menschen sollten in Workload-Accounts nie IAM-Benutzer mit langlebigen Schlüsseln haben. Verbinde IAM Identity Center mit deinem Unternehmens-Identitätsanbieter, provisioniere Benutzer und Gruppen per SCIM und vergib Zugriff über Berechtigungssätze, die Gruppen pro Account zugewiesen werden: Entwickler bekommen etwa Power-User-Zugriff in Non-prod und Lesezugriff in Prod.

Halte zwei Break-Glass-Identitäten mit Hardware-MFA bereit, offline aufbewahrt und überwacht. Für Root-Benutzer kann IAM den Root-Zugriff von Mitglieds-Accounts inzwischen zentral verwalten, eingeführt im November 2024. So kannst du Root-Zugangsdaten aus Mitglieds-Accounts komplett entfernen und die wenigen Root-only-Aufgaben von zentraler Stelle aus erledigen.

Logging und Erkennung

1. Ein Organisations-Trail in CloudTrail zeichnet API-Aktivität in jedem Account und jeder Region im Log-Archive-Account auf.
2. AWS Config zeichnet die Ressourcenkonfiguration überall auf, mit einem Aggregator in Security Tooling.
3. GuardDuty und Security Hub sind organisationsweit aktiviert, mit Security Tooling als delegiertem Administrator, damit neue Accounts automatisch abgedeckt sind.
4. Findings gehen an dein SIEM-System oder deine On-Call-Tools.

Netzwerk

Workload-Accounts besitzen ihre VPCs, aber nicht ihre Konnektivität. Der Network-Account stellt ein über Resource Access Manager geteiltes Transit Gateway bereit, zentralen Egress und Inspektion, DNS-Auflösung zwischen Cloud und Rechenzentrum sowie einen IP-Adressplan, idealerweise mit Amazon VPC IP Address Manager verwaltet, damit sich keine zwei VPCs überschneiden. Das AWS-VPC-Diagramm zeigt, was in jede Workload-VPC gehört, und das AWS-Multi-Region-Architekturdiagramm erweitert das Design über Regionen hinweg.

Aufbau: Control Tower oder Terraform

AWS Control Tower richtet die Organisation, die Kern-Accounts, einen Organisations-Trail, Config und einen Katalog von Controls ein und bietet Account Factory zum Anlegen neuer Accounts. Landing Zone Version 4.0, veröffentlicht am 17. November 2025, hat es laut den Control-Tower-Release-Notes deutlich flexibler gemacht:

• Die Integrationen für AWS Config, CloudTrail, Security-Rollen und AWS Backup wurden optional.
• Eine Security-OU ist nicht mehr Pflicht; du kannst deine eigene OU-Struktur definieren.
• Ein minimales Setup kann nur die Organizations-Integration und Controls nutzen.
• Config und CloudTrail bekommen dedizierte Ressourcen, und ein servicegebundener Config-Aggregator ersetzt die ältere Aggregation.

Terraform-Teams kombinieren Control Tower oft mit Account Factory for Terraform (AFT), das Accounts aus einem Git-Repository bereitstellt und anpasst. Seit September 2026 kann AFT Anpassungen im Plan-only-Modus ausführen, um Änderungen vor dem Anwenden zu prüfen. Andere verwalten Organizations komplett in Terraform oder nutzen die Lösung Landing Zone Accelerator on AWS. Alle drei funktionieren; entscheidend ist, dass das Anlegen von Accounts automatisiert und wiederholbar ist.

Account Vending

Neue Accounts sollten einsatzbereit ankommen: Eine Anfrage, oft ein Pull Request, legt den Account in der richtigen OU an, wendet die Baseline an (Identity-Center-Zuweisungen, Budgets und Alarme, eine an das Transit Gateway angebundene VPC, Standard-Security-Services) und übergibt ihn an das Team. Organizations begrenzt eine Organisation standardmäßig auf 10 Accounts, anpassbar über Service Quotas, also beantrage eine Erhöhung, bevor du sie brauchst.

Typische Fehler

• Workloads im Management-Account, wo keine SCP greift.
• Eine einzige flache Workloads-OU, sodass Produktion und Entwicklung dieselben Guardrails teilen.
• Guardrails, die erst geschrieben werden, nachdem Teams auf Annahmen gebaut haben, die sie brechen.
• Ein Log-Archive-Account, den Administratoren verändern können.
• Von Hand angelegte Accounts, jeder ein wenig anders.

Das Landing-Zone-Diagramm

So liest du es:

• Der Management-Account oben hält die Organisation und die Richtlinien; seine Kanten zu jeder OU sind Guardrail-Zuordnungen.
• Die Security-OU enthält Log Archive, das Logs aus jedem Account empfängt, und Security Tooling, das GuardDuty und Security Hub verwaltet.
• Die Infrastructure-OU enthält den Network-Account, dessen Transit Gateway die Workload-VPCs verbindet, und Shared Services für CI/CD.
• Die Workloads-OU trennt Prod- und Non-prod-Accounts; die Sandbox-OU bleibt isoliert.
• IAM Identity Center rechts gewährt Menschen Zugriff über Berechtigungssätze.
• Der Markdown-Block listet die ersten Guardrails auf.

Account-Strukturen klar zeichnen

• Zeichne OUs als Container und setz die Accounts hinein; die Hierarchie ist das Richtlinienmodell.
• Stell den Management-Account abseits dar. Er liegt außerhalb deiner Guardrails, und das Bild sollte das sagen.
• Zeichne nur Flüsse, die Account-Grenzen überschreiten: Logs ins Archiv, Netzwerkanbindungen, delegierte Administration, Identität.
• Benenne Accounts nach Funktion, nicht nach Account-Nummer.

Für das Sicherheitsmodell dahinter siehe das Zero-Trust-Architekturdiagramm. Wenn du Infrastruktur als Code verwaltest, zeigt das Terraform-Architekturdiagramm, wie du mit Terraform verwaltete Umgebungen zeichnest.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem Sicherheit-Pack einen Richtlinie-Node für den Management-Account und einen Identitätsanbieter für IAM Identity Center hinzu.
3. Füge vier Rahmen-Nodes aus dem Basis-Pack für die OUs hinzu: Security, Infrastructure, Workloads und Sandbox.
4. Füge in Security einen Objektspeicher-Node aus dem Cloud-Pack für Log Archive und einen Alarm-Node aus dem DevOps-Pack für Security Tooling hinzu. Füge in Infrastructure einen Router aus dem Netzwerk-Pack für den Network-Account und eine CI/CD-Pipeline aus dem DevOps-Pack für Shared Services hinzu.
5. Füge Recheninstanz-Nodes aus dem Cloud-Pack für die Prod-, Non-prod- und Sandbox-Accounts hinzu.
6. Verbinde den Management-Account mit jeder OU, die Accounts mit Log Archive und den Network-Account mit den Workloads, und füge einen Markdown-Block aus dem Basis-Pack mit den Guardrails hinzu.

Das Beispiel nutzt 14 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist eine AWS Landing Zone? Eine AWS-Umgebung mit mehreren Accounts, die nach deinen Sicherheits- und Betriebsstandards eingerichtet wird, bevor Workloads einziehen: Organisationseinheiten, Kern-Accounts, Identität, Guardrails, Logging und Netzwerk.

Brauche ich AWS Control Tower für eine Landing Zone? Nein. Control Tower ist der verwaltete Weg, eine aufzubauen, und Version 4.0 hat es flexibler gemacht. Du kannst Organizations auch mit Terraform, Account Factory for Terraform oder dem Landing Zone Accelerator verwalten.

Was ist der Unterschied zwischen einer SCP und einer RCP? Eine SCP begrenzt, was Principals in Mitglieds-Accounts tun können. Eine RCP begrenzt, was mit Ressourcen in Mitglieds-Accounts getan werden kann, und verhindert zum Beispiel, dass Buckets außerhalb der Organisation geteilt werden. Keine von beiden gewährt Berechtigungen.

Warum sollte der Management-Account leer bleiben? SCPs gelten nicht für Benutzer und Rollen im Management-Account, also liegt alles dort außerhalb deiner Guardrails. Er steuert außerdem die Abrechnung und die Organisation selbst, was ihn zum sensibelsten Account macht, den du hast.

Wie viele Accounts kann eine Organisation haben? Standardmäßig zehn. Das Kontingent lässt sich über Service Quotas anpassen, und nur der Management-Account kann die Erhöhung beantragen.

Kostenlos starten — ein Seat, keine Kreditkarte.