The Multi-Account Organisation Pattern That Scales

AWS Organizations + SCPs + per-team accounts. The pattern that scales to large companies and the gotchas that hide.

Structure

The multi-account AWS Organizations pattern is the foundation for any AWS estate above a few accounts. It provides isolation, governance, and billing organization in one structure. The pattern is widely adopted because it solves problems that single-account approaches cannot: blast radius isolation, environment separation, team-level autonomy with central oversight.

What good structure looks like:

• Organization root: management account.: The root of the org tree is a dedicated management account. This account does no workload; it manages billing, organizations, and audit. Workloads live in member accounts. The separation prevents accidental damage to org-level configuration.
• OUs for environments.: Organizational Units group accounts by purpose. Production OU, non-production OU, sandbox OU, security OU. The OU is the level at which policy applies; accounts inherit policy from their OU.
• Per-team accounts within OUs.: Each team has its own accounts within the appropriate OUs. Team A might have accounts in both production and non-production OUs. The team-level account provides isolation: team A's mistakes do not affect team B's resources.
• Centralized billing.: The management account consolidates billing across all member accounts. One bill, one payment relationship, one set of reservation purchases. The centralization simplifies financial operations.
• Decentralized operations.: Operations happen in member accounts. Each team operates their accounts independently within the constraints of organizational policy. The autonomy preserves agility while the centralized billing produces financial discipline.

The structure is the foundation. Other capabilities (SCPs, account factory, audit) build on this structure.

SCPs

Service Control Policies enforce guardrails across the organization. SCPs apply at the OU level and inherit down to member accounts. They constrain what IAM principals can do; SCPs are the absolute ceiling on permissions.

• SCPs enforce guardrails.: Required regions only (e.g., deny everything outside us-east-1 and eu-west-1). Denied services (no creating IAM users, no using deprecated services). Mandatory MFA for sensitive actions. The SCP enforces these as hard constraints.
• Required regions, denied services, mandatory MFA.: Common SCP patterns include region restrictions, service restrictions, and MFA requirements. Each pattern blocks a class of mistake or attack; the combination produces tight governance.
• Tested before applying.: SCPs can lock everyone out of an account if misconfigured. The discipline is to test SCPs in a non-production OU first; observe for unintended blocking; refine; then apply to production.
• SCPs can lock everyone out.: The most catastrophic SCP misconfiguration locks the management account itself out of the org. Recovery requires AWS Support intervention. Testing prevents this; never apply an SCP to the org root without thorough testing.
• Document the SCP set.: Each SCP is documented: what it does, why it exists, what risks it mitigates. New team members understand the constraints; future review revisits each SCP for ongoing relevance.

SCPs are powerful and dangerous. Used carefully, they produce excellent governance; used carelessly, they produce outages.

Gotchas

The multi-account pattern has known gotchas. Teams that recognize them in advance avoid the recurring pain; teams that do not recognize them learn each one through experience.

• Cost reporting per OU requires Cost Explorer setup.: Cost reporting at the OU level is not automatic. Cost Explorer can be configured for per-account, per-OU, per-tag breakdowns. The configuration is required; the data is not visible by default. The setup is a one-time effort.
• Cross-account permissions need careful design.: Resources in one account often need to be accessed from another. The patterns (cross-account roles, resource-based policies, AWS RAM) need design upfront. Retrofitting cross-account access onto a deployed architecture is harder than designing it in.
• Account closure is hard.: Closing an AWS account is a multi-step process with mandatory delays. Accounts cannot be closed quickly; planning around this prevents surprise. Deprecated accounts may stick around longer than expected.
• Plan account retention.: Some accounts should never close (legal hold, ongoing audit, billing history). Other accounts may need to close. The retention policy distinguishes which is which; the closure process respects the policy.
• Account aliases and email management.: Each account has a unique email; the email receives critical AWS notifications. The team needs an email management strategy that survives team turnover. Group aliases, mail rules, and shared inboxes all play a role.

Multi-account organization pattern is one of the most consequential AWS architectural decisions. Nova AI Ops integrates with Organizations and CloudTrail data, surfaces account-level patterns, and produces the cross-account visibility that the platform team needs to operate the structure effectively.