1.4 Design a Multi-Account AWS Environment
Official task mapping
SAP-C02 task 1.4: Organizations and sharing knowledge; account structure, governance and central logging. This lesson applies the official task to an original design exercise; it is not an exhaustive exam syllabus.
Prerequisites
Review Organizations, Control Tower and CloudTrail. Be able to explain the relevant failure boundary and access/cost model before choosing a service.
Account and governance design
Use accounts for isolation and ownership; group them into OUs that share controls. Keep production workloads out of the management account. Control Tower supports landing-zone governance, while Organizations policies and delegated administration provide additional service-specific controls. An SCP does not replace IAM or grant permissions.
Use dedicated log-archive and security administration accounts. Organization trails can be managed by the management account or an authorized CloudTrail delegated administrator. Protect the destination, encryption and retention, and confirm management/data event coverage.
RAM supports sharing specific resource types, including supported subnet and security-group sharing scenarios. Shared security groups require the same Organization and an owner that owns both the VPC and group; default groups/default VPC groups are excluded. RAM does not make every resource shareable or transfer ownership. Shared VPC designs separate network ownership from participant workloads; verify participant permissions rather than claiming security groups can never be shared.
Consolidated billing aggregates costs; member purchases can share eligible discounts under preferences. Shared discounts are not shared zonal capacity.
Organizations, RAM and logging architecture
| Element | Responsibility | Boundary to verify |
|---|---|---|
| Organization root/OUs | Group accounts and inherited controls | Allow paths and explicit denies |
| Management account | Organization/billing administration | Minimize workloads; special SCP treatment |
| Delegated administrator | Supported service administration | Service-specific registration and permissions |
| Network account | VPC/subnet, resolver and routing ownership | RAM resource support and participant rights |
| Log archive | Retention and controlled evidence access | Writer/read/deletion policies, keys and legal holds |
RAM can share supported TGWs, subnets, Resolver rules and other listed resource types. Sharing does not mean participants can modify every owner resource. A shared subnet reduces connection meshes but can couple quotas, routing and operational change ownership.
Design the logging workflow explicitly: configure source CloudTrail/flow/configuration coverage; use supported S3/CloudWatch delivery or subscriptions; protect the archive; optionally deliver supported streams through Amazon Data Firehose to analysis systems. Do not assume S3 replication is the only aggregator or call Firehose “Kinesis Data Firehose” as the current service name.
Object Lock and backup protections require compatible storage/configuration and carefully chosen retention. MFA Delete has separate operational constraints; neither should be enabled blindly in a study exercise. Confirm which principals can disable the source recorder as well as who can delete destination objects.
For a new account, test its account baseline, audit delivery, delegated administration, network share, owner budget and break-glass access before admitting production. Consolidated billing is not proof the landing zone or every security service was configured.
Scenario and rationale
A retailer needs independent product teams, central network administration and audit logs that developers cannot delete. Use workload accounts per isolation/ownership requirement, centrally owned shared subnets where suitable, a log archive and delegated security administration. Apply OU controls to production without burdening experimental sandboxes with every production constraint.
Reject one giant account with tags as its only boundary: tags aid ownership but do not create account isolation. Reject a separate organization for every team when consolidated governance and shared resources are explicit requirements.
Practice drill
Draw an account/OU tree, identify owners and label each control as preventive, detective or responsive. Trace who can create a workload, alter networking and read/delete logs. Include one approved exception path and test whether the management account’s special policy treatment was incorrectly assumed to apply to members.
References
- Official Domain 1 task guide
- Multi-account best practices
- Organization trails and delegated administration
- Shareable RAM resources
- Shared security-group requirements
Return to Domain 1. The drill is proposed study work, not a claim of a completed deployment.
Across the wiki
- Azure Governance — Management Groups, Policy & Locks — policy and governance (Azure)
- GKE Binary Authorization, Container Attestations, and Supply Chain Security — policy and governance (GCP)
- Policy Management on EKS — policy and governance (Kubernetes)
- AKS Governance — Azure Policy for Kubernetes and OPA Gatekeeper Guardrails — policy and governance (Azure)