Multi-Account Strategy, Account Topologies, and OU Hierarchies
Key Takeaways
- AWS Organizations is the foundation of enterprise multi-account design: one management (payer) account, member accounts, a single root, nested OUs, and optional policies
- Service control policies and most Organizations integrations require the all-features set; consolidated billing alone combines invoices but cannot enforce guardrails
- Split accounts when you need isolation, independent quotas, auditor evidence, or billing boundaries—never run business workloads in the management account because SCPs do not apply there
- A practical OU tree for a regulated enterprise is Security (log archive and audit), Infrastructure (network and shared services), Workloads with nested production and test OUs, Sandbox, and procedural OUs such as Suspended and Exceptions
- You cannot change which account is the management account, and a member account can belong to only one organization at a time
Multi-Account Strategy, Account Topologies, and OU Hierarchies
Quick Answer: Treat AWS Organizations as the foundation of enterprise governance. Keep the management account as the payer and policy hub only, place every workload in member accounts, and group those accounts into nested organizational units (OUs) so production, test, security, log-archive, and shared-services environments inherit the right controls under one consolidated bill.
An AWS account is a resource container and a hard isolation boundary for identity, quotas, and billing—not an IAM user. AWS Organizations groups accounts into a tree: one root, nested OUs, a single management account, and zero or more member accounts. SAP-C02 Task 1.4 asks you to choose that topology for a complex organization, not to cram every environment into one account and hope IAM groups are enough.
Why enterprises split accounts
AWS Well-Architected security guidance and the Organizing Your AWS Environment Using Multiple Accounts whitepaper (publication date 30 April 2025) treat a multi-account model as the default for security, reliability, operations, and cost. A single account cannot give an auditor a clean PCI boundary, cannot give two product teams independent service quotas, and cannot stop a compromised developer role from reaching production data if that data lives in the same account.
| Reason to split | What a dedicated account gives you | Typical exam scenario |
|---|---|---|
| Security profile | Distinct preventive policies, detective controls, and evidence packages | PCI cardholder data versus a general SaaS book of business |
| Blast-radius isolation | Compromised credentials and noisy neighbors stay inside one account | A sandbox ransomware event cannot encrypt production backups |
| Team autonomy | Independent IAM, pipelines, and change windows | A platform team versus a business unit |
| Data isolation | Fewer principals can ever reach regulated stores | Customer data subject to GDPR versus marketing analytics |
| Billing and showback | The account is the native billing boundary, including data-transfer line items | Chargeback to a subsidiary or cost center |
| Quotas | Service quotas are per account | A load test must not starve production API capacity |
Do not invent a “correct” account count. The whitepaper states that environments range from a few accounts to thousands and that AWS charges for resource usage, not for the number of accounts. The exam tests whether you split for isolation and governance—not whether you recited an unpublished quota.
Management account versus member accounts
The management account is the account that created the organization. You cannot later designate a different account as management. From it you create or invite accounts, attach organization policies, enable trusted access for AWS services, and register delegated administrators. It is also the payer account: every member’s charges roll up under consolidated billing.
That power is exactly why you keep it empty of business workloads. Service control policies (SCPs) do not restrict IAM users or roles in the management account. A production database in the management account would sit outside the preventive guardrails you spent months designing. AWS Control Tower documentation is explicit: do not run production workloads from the Control Tower management account.
Member accounts hold workloads. A member can belong to only one organization at a time. Accounts you create in Organizations receive an IAM role (by default OrganizationAccountAccessRole) that the management account can assume. Invited accounts do not get that role automatically; after they accept the handshake you create an equivalent role if central break-glass access is required. Member accounts created in Organizations have no root user credentials by default. Everyday human access should go through AWS IAM Identity Center permission sets, not long-lived IAM users in each account.
Delegated administrators let a member account operate an Organizations-integrated service (CloudTrail, Config, GuardDuty, Security Hub, and others) so operators never live in the management account. SCPs still apply to those delegated member accounts—unlike the management account.
Feature sets: consolidated billing versus all features
Organizations offers two feature sets. Confusing them is a classic Professional-level trap.
| Feature set | What you get | What you cannot do |
|---|---|---|
| Consolidated billing | Single payer, combined usage that can produce volume pricing benefits, and the ability to share Reserved Instances and Savings Plans according to billing preferences | SCPs, resource control policies (RCPs), most other organization policy types, and many service integrations |
| All features (recommended; default for new organizations) | Everything in consolidated billing plus policies, delegated administrators, and service integrations | You still must enable each policy type (for example SCPs) before you can attach those policies |
If an organization started on consolidated billing only, enabling all features requires invited member accounts to accept an ENABLE_ALL_FEATURES handshake. Accounts created in the organization do not need that extra approval. Exam stems that say “SCPs are unavailable” or “the policy type cannot be enabled” are almost always this feature-set issue.
Consolidated billing still matters after you enable all features. The management account receives the invoice. Combined usage can produce volume discounts. You then layer cost allocation tags and Cost Categories on that bill. For Task 1.4, remember: billing centralization is not security centralization. Tags never replace account isolation.
OU design: hierarchy, inheritance, and recommended topology
The root is created automatically. It is not an OU. You get exactly one root. Authorization policies (SCPs and RCPs) attached to the root apply to member accounts and OUs beneath it, not to the management account. Declarative policies attached to the root apply more broadly, including the management account—do not mix those policy families when you reason about inheritance.
An OU groups accounts (and child OUs) that should receive the same controls. Excluding the root and the accounts in the lowest OUs, the hierarchy can be five levels deep. Nesting is how you get coarse then fine guardrails: an organization-wide rule that no account may disable CloudTrail, a Production OU rule that forbids Internet-facing load balancers, and a PCI OU rule that restricts Regions.
Follow AWS multi-account strategy guidance for a regulated enterprise:
Foundational OUs
- Security OU — only core security accounts. The usual pair is Log Archive (durable CloudTrail, Config, and VPC Flow Logs in Amazon S3, typically with Object Lock or equivalent retention controls) and Security Tooling / Audit (delegated administrator for GuardDuty, Security Hub, Inspector, and Config aggregators). Keep this OU small. Extra security experiments belong in another OU so auditors can reason about a tiny blast radius. AWS Control Tower provisions log archive and audit shared accounts into this pattern during landing-zone setup.
- Infrastructure OU — Network (Transit Gateway, AWS Cloud WAN, shared interface endpoints, inspection VPCs) and Shared Services (directory integrations, image pipelines, inner-source artifact stores).
Application and experimental OUs
- Workloads OU with nested Production and Non-production / Test OUs so production SCPs are stricter while still inheriting organization-wide logging rules.
- Sandbox OU — builder experimentation with aggressive deny lists (no leaving the organization, no public Amazon S3, no routes to production).
Procedural OUs
- Suspended — deny almost all actions except billing and break-glass while you investigate.
- Exceptions — rare accounts that cannot take the standard SCP; compensate with extra detective controls and time-boxed waivers.
- Transitional and Policy Staging — park invited legacy accounts, or test a new SCP against a canary account, before moving it under Production.
Do not flatten “prod and test in one account, two VPCs.” VPCs are not a billing boundary, not a quota boundary, and not a strong identity boundary. Nested OUs plus separate accounts are the professional answer.
Exam scenario: regulated enterprise topology
A multinational insurer already has a messy management account running an old production VPC. Compliance now requires PCI for card payments, multi-year log retention, and proof that developers cannot disable logging.
The professional design is not “add IAM deny statements in the existing account.” Create (or complete) an organization with all features. Leave the management account as payer only and migrate the old VPC out. Create a Security OU with dedicated Log Archive and Audit accounts. Create an Infrastructure OU for shared networking. Create Workloads/Production/pci-payments and Workloads/Production/general-insurance as separate member accounts, plus Workloads/Test for lower environments. Attach organization-level logging first, then environment SCPs. Vend new accounts through Organizations APIs or Account Factory so a central access role exists on day one.
If a business unit demands “our own AWS Organization” solely to see a bill, that usually fails Task 1.4: they lose central SCPs, organization CloudTrail, and AWS RAM sharing. Give them a nested OU, a Cost Category, and a member account instead.
SAP-C02 decision rules
- Split accounts when isolation, quotas, evidence, or billing must be independent; do not split only to look mature.
- Never place production, log archives, or security tooling in the management account.
- Design OUs for policy inheritance (who shares a guardrail), not purely for the human org chart—though those often coincide.
- Enable all features before promising SCPs or AWS Control Tower.
- Treat Organizations as the foundation. Control Tower, RAM, organization trails, and Config aggregators all assume this tree already exists.
A global payments processor must isolate PCI DSS cardholder data from a general insurance book of business, keep a single invoice, and apply different preventive controls. Insurance developers currently have AdministratorAccess in their account. Which topology best meets the requirement?
An enterprise currently uses AWS Organizations with only the consolidated billing feature set. Security wants to deny member accounts from leaving the organization and from creating resources in unapproved Regions. What must happen first?
A CIO asks why test and production cannot stay in one AWS account if IAM roles are separate. Finance still wants Reserved Instance and Savings Plans discounts to apply across environments. What should you recommend?