AWS Organizational Unit Structure: Designing for Scale and Security

Organizational Unit structure is one of those infrastructure decisions that's easy to get wrong early and hard to change later. Adding SCPs to an OU propagates to all accounts within it — which is the point, but it also means an OU structure designed for small scale creates problems when accounts multiply. Conversely, an over-engineered OU hierarchy designed for imagined future complexity becomes an administrative burden that slows down routine operations.

Good OU design balances three concerns: policy inheritance (which accounts need the same SCPs applied automatically), operational grouping (which accounts are managed together in daily operations), and cost attribution (which accounts belong to which cost center or team). These don't always align, which requires conscious tradeoffs.

AWS Reference Architecture OUs

AWS's own multi-account reference architecture (implemented by Control Tower) uses the following top-level OU structure as a starting point:

• Security: Log Archive and Audit accounts — the foundational security infrastructure accounts
• Infrastructure: Shared services (Transit Gateway, DNS, artifact repositories), Network accounts
• Workloads: Production and non-production workload accounts, potentially with sub-OUs per application or business unit
• Sandbox: Individual developer sandbox accounts with more permissive policies and no production traffic
• Policy Staging: Accounts used for testing SCP changes before promoting to production OUs
• Suspended: Accounts being decommissioned, with restrictive SCPs applied (deny all but the minimum required for cleanup)

This structure separates accounts by both function (Security vs. Workloads vs. Infrastructure) and sensitivity level (Production vs. Sandbox). The separation enables targeted SCP application: Sandbox accounts get permissive policies that allow experimentation; Production accounts get strict guardrails.

Workloads OU Design Patterns

The Workloads OU is typically where most accounts live and where OU design decisions have the most operational impact. Three common patterns:

Flat by environment: Two sub-OUs — Production and Non-Production. All production accounts in one OU, all dev/staging accounts in another. Simple to manage, clear policy boundary between prod and non-prod. Works well when your production accounts are relatively homogeneous and don't need different SCPs from each other.

By application/service team: Sub-OUs per application or team: Workloads/Payments, Workloads/Analytics, Workloads/Platform. Each sub-OU has its own production and non-production accounts. Enables team-level policy customization and makes cost attribution by team straightforward. Creates more OUs to manage and requires governance of who can create new OUs.

By regulatory requirement: Sub-OUs for different compliance contexts: Workloads/Standard, Workloads/PCI, Workloads/HIPAA. PCI and HIPAA OUs have additional restrictive SCPs appropriate to those frameworks. This is the right pattern when you have workloads with meaningfully different compliance requirements that need enforced separation.

In practice, most organizations use a hybrid: environment-based at the top (Production/Non-Production/Sandbox) with sub-OUs for teams or compliance domains within the Production OU where different SCPs are genuinely needed.

SCP Inheritance and Design

SCPs at a parent OU level apply to all descendant OUs and accounts. Design your OU hierarchy to take advantage of this inheritance:

SCPs at the Root level (attached to the Root OU) apply to all accounts. Put your universal guardrails here: deny leaving the organization, deny disabling CloudTrail, deny disabling Config. Every account should have these regardless of workload type.

SCPs at the Workloads OU level apply to all workload accounts. Production-appropriate guardrails go here: region restrictions, prohibited services, security logging requirements.

SCPs at the Production sub-OU level add additional constraints for production specifically: perhaps stricter instance type limits, mandatory encryption requirements, or approvals for specific dangerous operations.

This layered approach means a Production account inherits guardrails from Root, from Workloads, and from Production. You add constraints as you go deeper in the hierarchy rather than repeating the same restrictions at every level.

Account-to-OU Mapping Rules

Establish clear rules for which OU new accounts go into. Without explicit rules, team members create accounts in whatever OU seems reasonable, leading to inconsistent policy application. Document:

• What criteria determine an account is "production" (serving live customer traffic, running non-reversible processes, holding production data)
• What accounts qualify for the Sandbox OU (individual developer accounts with no shared workloads, no access to production data)
• Which teams can create accounts in which OUs
• The approval process for creating accounts in regulated OUs (PCI, HIPAA)

Document these rules in a runbook and enforce them through your account vending process. Account Factory for Terraform can validate OU placement during the account creation pull request review.

Evolving Your OU Structure

OU structures change as organizations grow. Account moves between OUs are low-risk operations (no resource disruption, immediate policy change). OU restructuring (creating new OUs, renaming OUs, reorganizing hierarchy) requires more care because all existing SCP references need to be updated.

Before significant restructuring, audit what SCPs are attached to each OU and what StackSets or other automation reference OUs by name. A restructure that renames an OU breaks any automation that references it by name rather than ID. Use OU IDs (rather than names) in automation wherever possible for resilience against renaming.

Plan OU structure evolution in quarters rather than reacting ad-hoc. When teams request a new OU, evaluate whether the request reflects a genuine policy or governance need or whether the existing structure can accommodate it with a new account placement. Excessive OU proliferation creates management overhead without governance benefit.

Related Reading

• AWS Organizations best practices — organizational design beyond OU structure
• Service Control Policies — policy inheritance and OU-level guardrails
• AWS Control Tower setup — managed OU creation and baseline application
• Multi-account monitoring — observability across your OU hierarchy

FAQ

How deep should an OU hierarchy go?

AWS supports up to 5 levels of OU nesting (Root → Level 1 → Level 2 → Level 3 → Level 4 → Accounts). In practice, most organizations don't need more than 3 levels (Root → Top-level → Sub-level → Accounts). Deeper hierarchies make it harder to reason about which SCPs apply to a given account — you have to trace the inheritance chain from Root through every ancestor OU. Keep the hierarchy as flat as your governance needs allow.

Should I create OUs for individual teams?

Only if different teams genuinely need different SCPs applied. If team A and team B have the same compliance requirements and the same production standards, putting them in the same OU simplifies management without sacrificing governance. Create team-level OUs when teams have meaningfully different compliance contexts or when team-level billing attribution is required by your finance team.

What should I do with inactive or decommissioned accounts?

Move decommissioned accounts to a Suspended OU before closing them. Apply a very restrictive SCP to the Suspended OU that denies all actions except those required for cleanup (billing read access, some S3 operations for retrieving logs). This prevents anyone from accidentally using the account while it's being decommissioned. AWS account closure has a 90-day recovery period — moving to Suspended OU maintains the guardrails during that period.