Amazon SAP-C02: Organisatorische Komplexität & Multi-Account-Strategie — Lernleitfaden
Teil des AWS Solutions Architect Professional SAP-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.
Multi-Account-Strategie und Account Vending
Eine Multi-Account-Strategie beginnt mit einer klaren Trennung der Verantwortlichkeiten: Sicherheit und Audit, gemeinsam genutztes Networking, Produktions-Workloads und Sandbox- oder Entwickler-Accounts. Die Verwendung von AWS Organizations entweder mit AWS Control Tower oder einer benutzerdefinierten Landing Zone erzwingt diese Trennung vom ersten Tag an. Die Account Factory von Control Tower bietet ein Account-Vending-Muster, das die Erstellung von Konten, grundlegende IAM-Rollen, VPC-Vorlagen und Guardrails automatisiert, während eine benutzerdefinierte Landing Zone, die mit CloudFormation/CDK und Service Catalog erstellt wird, mehr Flexibilität für maßgeschneiderte Netzwerke und Governance bietet. Der primäre Kompromiss besteht zwischen operativem Mehraufwand und der Reduzierung des Blast-Radius: Mehr Konten vergrößern die Verwaltungsoberfläche (Automatisierung, kontoübergreifende Rollen, Einblick in die Abrechnung), begrenzen aber das Risiko einer Kompromittierung der Domäne und vereinfachen die Compliance pro Konto. Entscheidungen beim Networking – VPC-Sharing mit AWS Resource Access Manager, Transit Gateway im Hub-and-Spoke-Modell oder isolierte VPCs mit VPC-Peering – führen zu Kompromissen bei Kosten und Latenz. Gemeinsam genutzte Dienste (DNS, NAT, Active Directory) befinden sich oft in einem Networking- oder Shared-Services-Account; das Account-Vending sollte neue Konten automatisch an diese gemeinsam genutzten Ressourcen anbinden oder delegierte VPCs bereitstellen. Planen Sie Quotas und Automatisierung: Zentralisieren Sie Pipelines für grundlegende Artefakte, damit die Skalierung der Konten den manuellen Aufwand nicht vervielfacht.
Governance: SCPs, Control Tower Guardrails und Organisationsrichtlinien
Governance in einer AWS-Umgebung mit mehreren Konten hängt von der Durchsetzung von Richtlinien auf Organisationsebene und von delegierten Laufzeitkontrollen ab. Service Control Policies (SCPs) legen die Obergrenze für erlaubte Aktionen über alle Konten hinweg fest; sie sind mächtig, aber unnachgiebig – deny-Regeln in der Root-OU verhindern sogar, dass Administratoren Service-linked Roles erstellen oder Dienste nutzen können, es sei denn, dies wird explizit erlaubt. Control Tower bietet vorgefertigte Guardrails (mandatory, strongly recommended, elective), die gängige SCPs und Config-Regeln implementieren, kann aber für fortgeschrittene Dienstmuster restriktiv sein. Die Design-Entscheidung dreht sich um zentralisierte vs. delegierte Governance: Eine strikte Deny-Liste auf Root-Ebene maximiert die Compliance, erhöht aber die Reibung für Produktteams und Automatisierung, während permissive Baselines mit Permission Boundaries und IAM-Rollenkontrollen eine schnellere Entwicklergeschwindigkeit ermöglichen. Protokollierungs- und Audit-Richtlinien (organisationsweiter CloudTrail, AWS Config Aggregator, delegierte Administratoren für Security Hub und GuardDuty) müssen vom Management-Account aus durchgesetzt werden, um unveränderliche Audit-Trails zu gewährleisten. Ein pragmatischer Ansatz ist eine mehrschichtige Governance: SCPs auf Organisationsebene für einschneidende Einschränkungen, Permission Boundaries zur Begrenzung des Entwickler-Scopes und automatisierte Guardrails, die durch die CI/CD der Landing Zone angewendet werden, um Konsistenz ohne manuelle Freigabeprozesse zu wahren.
Sicherheitsgrenzen: Kontoübergreifende Rollen, KMS und Ressourcenrichtlinien
Kontoübergreifender Zugriff ist ein Kernmuster und muss mit dem Prinzip der geringsten Rechte (Least Privilege) und starken Vertrauenskontrollen implementiert werden. Das gängige Muster delegiert den Zugriff über IAM-Rollen in jedem Konto, die von vertrauenswürdigen Prinzipalen mit STS angenommen werden: Rollen für CI/CD-Deployments, Monitoring (CloudWatch/SSM) und Integrationen von Drittanbietern sollten gegebenenfalls MFA erfordern und External IDs für den Partnerzugriff verwenden. Ressourcenbasierte Richtlinien für S3-, SQS- und KMS-Schlüssel ermöglichen direkten kontoübergreifenden Zugriff, aber KMS erhöht die Komplexität: Eine KMS-Schlüsselrichtlinie muss die Prinzipale und Dienste des vertrauenden Kontos explizit zulassen, und für temporären Zugriff können Grants oder Grants mit Einschränkungen erforderlich sein. Die Verwendung eines zentralen KMS-Schlüssels im Logging- oder Security-Account vereinfacht die zentrale Verschlüsselung, schafft aber eine operative Kopplung und potenzielle Verfügbarkeitsüberlegungen; Schlüssel pro Konto reduzieren den Blast-Radius, vervielfachen aber den Aufwand für Schlüsselrotation und Grant-Management. Häufige Fallstricke sind SCPs, die unbeabsichtigt die Erstellung von KMS- oder Service-linked Roles verweigern, Bucket Policies, die mit SCPs in Konflikt stehen, und das Vergessen, die Delegierungsrolle zu Config/CloudTrail im Collector-Account hinzuzufügen. Design-Entscheidungen sollten die administrative Einfachheit, das Prinzip der geringsten Rechte und die kontoübergreifende Latenz abwägen.
Zentralisierte Protokollierungs-, Abrechnungs- und Automatisierungsmuster
Zentralisierte Protokollierung und Abrechnung sind das Rückgrat der Transparenz im Unternehmen. Ein CloudTrail für die Organisation, dessen Trails in einen S3-Bucket in einem zentralen Sicherheits- oder Audit-Konto geliefert werden, gewährleistet eine manipulationssichere Erfassung von Ereignissen; ergänzen Sie dies mit CloudWatch Logs-Abonnementfiltern zu Kinesis Data Firehose für Analysen und aggregieren Sie Config-Daten mit einem Aggregator in dasselbe Konto. Kostentransparenz erfordert eine konsolidierte Abrechnung in Organizations, Cost Explorer, Budgets und zentral bereitgestellte Cost and Usage Reports; Tag-Governance und eine automatisierte Durchsetzung von Tags über Config-Regeln verbessern die Genauigkeit der internen Weiterverrechnung. Automatisierungsmuster, die über Konten hinweg skalieren, verwenden üblicherweise eine gemeinsam genutzte CI/CD-Pipeline oder ein Deployment-Konto, das kontoübergreifende Deployment-Rollen annimmt, oder CloudFormation StackSets mit einem delegierten Administrator für die Massenbereitstellung. Verwenden Sie Systems Manager Automation und State Manager für kontoübergreifendes Patching und Konfiguration, aber denken Sie daran, dass jedes Konto die erforderlichen Rollen und SSM-Berechtigungen gewähren muss. Die Kompromisse liegen zwischen Zentralisierung und Latenz: Die zentrale Aggregation reduziert doppelten Speicherplatz und vereinfacht die Analyse, schafft aber Abhängigkeiten von Netzwerk und Verfügbarkeit; die verteilte Protokollierung dupliziert Daten, isoliert aber Ausfälle. Planen Sie die Aufbewahrung, Lifecycle-Regeln, regionenübergreifende Replikation für DR und die Verwaltung von Verschlüsselungsschlüsseln im Einklang mit den Compliance-Anforderungen.
Praktisches Problem: Anwendungsfallszenario
Szenario: Contoso Media betreibt eine AWS-Unternehmensumgebung mit vorhandenem Organizations und Control Tower. Sie haben ein Verwaltungskonto, ein Shared-Services-Netzwerkkonto und 20 Mitgliedskonten, auf denen Produktions-, Staging- und Entwickler-Workloads in zwei Regionen ausgeführt werden.
Herausforderung: Contoso muss schnell 15 neue Projektkonten onboarden und dabei eine zentralisierte Protokollierung, geeignete SCP-Leitplanken, eine automatisierte Netzwerkanbindung an das Shared-Services-Konto über Transit Gateway und Deployment-Pipelines sicherstellen, die keine manuelle IAM-Einrichtung pro Konto erfordern.
Empfohlener Ansatz:
- Verwenden Sie die Control Tower Account Factory oder einen automatisierten AWS Organizations API-Workflow, um Konten mit einer Basisvorlage für CloudFormation/CDK bereitzustellen. Diese Vorlage registriert das Konto in AWS Config, aktiviert einen CloudTrail für die Organisation, der auf den S3-Bucket des Audit-Kontos verweist, und wendet die erforderlichen Tags an.
- Hängen Sie SCPs auf OU-Ebene an, die einschneidende Verbote durchsetzen (z. B. das Löschen von Schlüsseln über Regionen hinweg und nicht zugelassene Regionen verbieten), während OUs für Entwicklungsberechtigungen weniger restriktiv gehalten werden; validieren Sie SCPs in einer Sandbox, bevor Sie sie breit anwenden.
- Konfigurieren Sie das Transit Gateway im Shared-Services-Netzwerkkonto und erstellen Sie Attachments für das Transit Gateway VPC-Attachment jedes neuen Kontos. Verwenden Sie dazu Infrastructure-as-Code und einen delegierten Admin oder eine kontoübergreifende Rolle, die der Bereitstellungsprozess annimmt, um die Erstellung der Attachments und die Weitergabe von Routen zu automatisieren.
- Stellen Sie eine zentralisierte CI/CD-Deployment-Pipeline in einem Tooling-Konto bereit, die kontoübergreifende IAM-Rollen (assume-role) verwendet, die durch den Kontobereitstellungsprozess erstellt wurden. Nutzen Sie CloudFormation StackSets (delegierter Admin) oder kontoübergreifende CodePipeline-Aktionen für die anfängliche Basis-Provisionierung und laufende Updates.
Begründung: Die Automatisierung der Kontobereitstellung mit Basis-Artefakten setzt Governance durch und minimiert gleichzeitig manuelle Schritte. Das Delegieren von Netzwerk- und Deployment-Aufgaben über kontoübergreifende Rollen und Transit Gateway zentralisiert gemeinsam genutzte Dienste, reduziert den „Blast Radius“ (Schadensradius) und skaliert das Onboarding, ohne die Sicherheit oder Überprüfbarkeit zu beeinträchtigen.
Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Bestehe deine Prüfung →