Skip to content

PATTERN Cited by 1 source

Start with a single AWS Organization by default

Intent

For an enterprise adopting AWS, begin with a single AWS Organization containing all accounts and rely on OUs + SCPs for internal governance. Only consider multiple organizations when a specific isolation requirement — regulatory mandate, M&A situation, sandbox preflight need, subsidiary autonomy — cannot be satisfied by OU- level mechanisms.

The AWS recommendation

The 2026-05-11 AWS Architecture Blog post states the posture directly:

"When helping customers design their AWS multi-account strategy, I recommend starting with a single organization and only considering multiple organizations when the isolation requirements outweigh the operational benefits of centralization." (Source: sources/2026-05-11-aws-choosing-between-single-or-multiple-organizations)

And:

"Most enterprises, especially those adopting AWS as part of a centralized IT strategy, find that a single organization is the best fit." (Source, ibid)

The default is not a blanket rule — it is a starting posture driven by the operational-efficiency side of the single-vs-multiple trade-off, with four named affirmative pushes for single:

  1. Centralised visibility and governance across accounts.
  2. Shared corporate security policy across business units.
  3. Consolidated billing with volume discounts.
  4. Resource sharing (VPCs, directory services, AMIs) between accounts.

Why start single

Five structural reasons:

  1. Structural reversibility is asymmetric and hard in both directions — merging multiple organizations into one is difficult (account migrations, IAM reconciliation, billing re- stitching), and splitting one organization into multiple is also difficult. But starting with one keeps optionality open: the enterprise can split later if specific needs arise, without having to integrate what was never separated.
  2. Pricing incentives bias toward aggregation — consolidated billing + volume discounts are visible as line items on the monthly bill; fragmenting prematurely pays a recurring cost.
  3. AWS-native cross-account tooling assumes one organization — StackSets, RAM, Observability Access Manager, tag policies, and most other "organization-wide" primitives are scoped to one Organization. Multiple organizations force re-implementation of cross-organization tooling.
  4. Operational simplicity compounds — one management console, one set of SCPs to maintain, one IAM trust surface to reason about, one compliance-reporting aggregator. Each new organization adds duplicated operational surface area.
  5. Most isolation needs are served by OUs + SCPs — workload- purpose separation, environment separation, regulatory scope for non-legally-mandated compliance, all fit inside one organization's OU tree.

When the default doesn't fit

The pattern does not apply when any of the following is true:

  • Legally-mandated entity-level segmentation exists (banking divisions, regulated insurance lines, healthcare entities) — consider patterns/separate-organization-per-regulated-division.
  • M&A is in progress with newly-acquired companies keeping their existing AWS footprint — the acquired organization stays as its own organization during integration.
  • Subsidiaries / franchises insist on organizational autonomy — accepting the operational cost of separate organizations to preserve their independence.
  • Sandbox preflight of dangerous governance changes is needed — consider patterns/sandbox-organization-for-scp-testing.
  • Maximum blast-radius containment between business units is required (catastrophic incident or security compromise in one unit must structurally not affect another).

In those cases, start with multiple organizations only for the units that require it. A hybrid shape — regulated subsidiary in its own organization, rest of the enterprise in one consolidated organization — is a valid and common structure.

What starting single looks like

  1. One Organization, one management account. The management account is kept minimal-privilege — no production workloads, no long-lived access keys, and MFA / SSO only.
  2. OU hierarchy sized for growth. Security OU, Infrastructure OU, Workloads OU (with Prod / Nonprod / Sandbox sub-OUs), Suspended OU for offboarded accounts. Depth kept shallow (≤4 levels) to stay well under the limit.
  3. SCP baselines attached at root (deny root user, deny leaving org, deny unapproved regions, deny unapproved services), refined at each OU level.
  4. Account vending automation — accounts are created via a pipeline (e.g. Control Tower + account factory, or custom Step Functions), placed in the right OU automatically, with baseline security configurations applied on creation.
  5. Consolidated billing with chargeback via Cost Explorer — per-account or per-tag cost attribution for internal reporting, aggregate for AWS billing.
  6. Central observability — forwarded CloudTrail, CloudWatch Logs, Config to a dedicated logging account in the Security OU.

Composition with other patterns

  • patterns/multi-account-isolation (workload-purpose separation) — composes cleanly inside one organization; different OUs for different workload purposes.
  • concepts/account-per-tenant-isolation (SaaS-tenant separation) — composes cleanly inside one organization; ProGlove's ~6,000-tenant-account fleet lives in one organization with OU-based policy scoping.
  • patterns/cross-partition-failover — orthogonal axis; each partition has its own Organization anyway (mandatory separate for European Sovereign Cloud, optional for GovCloud).

Caveats

  • Default ≠ mandate. The pattern is a starting posture. Enough evidence of a specific isolation requirement justifies deviation. The decision should be driven by actual regulatory / M&A / autonomy / blast-radius requirements, not by enthusiasm for isolation-by-default.
  • Single-organization is not "flat". A single organization with a well-designed OU hierarchy has all the policy-scoping flexibility of multiple organizations — without the billing and resource-sharing penalties. Skipping the OU design step and running a flat single organization is a different (and worse) pattern.
  • The single-organization management account is load-bearing. Compromising it compromises every member account's trust surface. Platform teams must operate it as a minimal-privilege root.
  • The pattern is about starting posture, not permanence. The post's closing framing — "long-term benefits of consolidation often make a compelling case for eventual migration to a single organization" — acknowledges that companies who start with multiple organizations (often because of historical reasons) may end up consolidating back to one.

Seen in

Last updated · 542 distilled / 1,571 read