Skip to content

CONCEPT Cited by 3 sources

Organizational unit (AWS OU)

What it is

An organizational unit (OU) is the nested-grouping primitive inside an AWS Organization: AWS accounts are grouped into OUs by some shared axis (business unit, environment, workload purpose, tenant cohort, regulatory scope), OUs can contain other OUs forming a tree, and Service Control Policies attach to OUs and are inherited by every account underneath.

"Group accounts into organizational units (OUs) by use-case or workstream." (Source: sources/2026-05-11-aws-choosing-between-single-or-multiple-organizations)

OUs are the primary policy-scoping mechanism inside one organization: you don't typically attach SCPs to individual accounts; you put accounts into the right OU and let inheritance do the work.

OU tree as policy hierarchy

A typical enterprise OU hierarchy:

Organization root
├── Security OU            (CloudTrail, GuardDuty, audit accounts)
├── Infrastructure OU      (shared networking, DNS, logging)
├── Workloads OU
│   ├── Prod OU            (production workloads)
│   │   ├── Prod-Team-A
│   │   ├── Prod-Team-B
│   │   └── ...
│   ├── Nonprod OU         (dev/staging/test)
│   └── Sandbox OU         (exploration; permissive SCPs)
├── PolicyStaging OU       (SCP preflight; isolated from prod)
└── Suspended OU           (offboarded accounts, deny-all SCP)

SCPs attached at each level stack via intersection: the effective ceiling at any account is the intersection of all SCPs on the path from root to that account. An account cannot do anything that any SCP in its path denies.

OU vs multiple-Organizations

OUs are the within-organization answer to "I want different policy profiles for different sets of accounts." Multiple organizations are a different answer to a different question: "I want different sets of accounts to have structurally separate IAM, billing, and governance surfaces — not just different SCPs."

Distinction OU (within one organization) Separate organization
Policy scope Inherited via SCP Fully independent
IAM Shared per-partition IAM Fully independent
Billing Consolidated (aggregates) Independent, no volume-discount sharing
Resource sharing Trivial (one RAM namespace, shared VPCs, Cloud Map, etc.) Requires cross-account trust between external accounts
Cross-scope primitives AWS Observability Access Manager, Transit Gateway RAM sharing, Stack Sets None
Management surface One Organizations console One per organization

The rule of thumb: use OUs for governance-shape differences; reserve separate organizations for structural-boundary requirements (regulatory mandates, M&A, sandbox preflight).

OU use cases on the wiki

  • Workload-purpose separation — ProGlove-style account-per-tenant platforms use OUs to organise tens of thousands of accounts into shape classes (tenant OU vs infrastructure OU vs security OU); the account is the tenant isolation boundary, the OU is the policy grouping boundary.
  • Environment separation — Prod OU vs Nonprod OU vs Sandbox OU, each with different permissive / restrictive SCPs.
  • Regulatory scope — if part of the workload is regulated (PCI / HIPAA) and part is not, a regulated OU + strict SCPs can enforce compliance without promoting the whole organization to the regulated profile. (For legally-mandated entity-level segmentation the source recommends a separate organization instead.)
  • Sovereign-partition mirror — for companies running in both standard and sovereign partitions, the OU + SCP hierarchy in each partition's organization is usually a near-mirror of the other; "manage the same organizational units (OUs) and policies for the AWS European Sovereign Cloud by reusing your existing deployment automation." (Source: sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty)

Governance via OU

The four-step AWS Organizations governance model:

  1. Add accounts — create new or invite existing accounts.
  2. Group accounts into OUs by use-case or workstream.
  3. Apply policies — SCPs (permission boundaries), Backup Policies, Tag Policies, etc., attached to OUs or accounts.
  4. Enable AWS services integrated with AWS Organizations.

(Source: sources/2026-05-11-aws-choosing-between-single-or-multiple-organizations)

OU is the substrate of step 2; SCP attachment + inheritance is the substrate of step 3.

Caveats

  • OU depth is bounded. AWS Organizations has a maximum OU nesting depth (5 levels as of 2024); deeply nested hierarchies run into both the limit and the operational complexity of tracing effective SCPs through many levels.
  • SCP size and attachment-count limits constrain policy composition; complex policy sets need to be factored into OUs.
  • OU boundary is policy, not structural. An SCP-misconfiguration or a new AWS service that SCPs don't yet gate can leak across the OU boundary in ways that structural boundaries (separate accounts, separate organizations) prevent by construction.
  • OU is not an IAM-trust boundary. Principals in an account do not automatically trust principals in a sibling account just because both accounts are in the same OU — cross-account IAM roles still need to be explicitly configured.

Seen in

Last updated · 542 distilled / 1,571 read