Skip to content

CONCEPT Cited by 1 source

Single-vs-multiple-Organizations decision

What it is

The single-vs-multiple-Organizations decision is the architectural choice enterprises face when adopting AWS Organizations: run one organization that contains all AWS accounts for the enterprise, or run several organizations as parallel governance domains with no shared IAM, billing, or policy surface.

"Most AWS customers adopt a single organization and create multiple accounts within it. However, some enterprises—particularly those with highly independent business units or strong regulatory requirements or those experiencing mergers and acquisitions—explore the option of creating multiple organizations." (Source: sources/2026-05-11-aws-choosing-between-single-or-multiple-organizations)

The decision is structurally distinct from two adjacent axes:

  • AWS partition — a hard boundary for sovereignty / jurisdictional isolation; partition choice is regulatory, not architectural. Organization topology is chosen within a partition.
  • Account-per-tenant isolation — SaaS tenant-count-scaling axis inside a single organization, typically via OUs. Scales to thousands of accounts. Does not imply multiple organizations.

All three axes compose: a regulated financial services enterprise might run separate organizations per division (this axis), across multiple partitions (partition axis), with account-per- tenant inside each organization for its SaaS products (tenant axis). The three are orthogonal.

The decision criteria

The 2026-05-11 source names ten criteria across which the two shapes differ; the axis reduces to operational efficiency vs risk isolation as the core trade-off.

Push toward single:

  • Shared corporate security policy across all business units.
  • Material cross-account resource sharing (VPCs, AMIs, directory services, shared services architectures).
  • Volume-sensitive pricing that benefits from consolidated billing with volume discounts.
  • Centralized compliance enforcement via SCPs, AWS Config, and AWS Security Hub as a single-plane governance surface.
  • Thousands-of-account growth projection (account-per-tenant, workload-purpose isolation) — all served by OU hierarchy within one organization.

Push toward multiple:

  • Independent business units with separate leadership + governance + security requirements (subsidiaries, franchises).
  • Regulated industries where strict entity-level segmentation is legally required (banking, insurance, healthcare).
  • Mergers and acquisitions where the newly-acquired company keeps its existing AWS footprint (transient or permanent).
  • Maximum blast-radius containment between business units: a misconfiguration, security incident, or policy change in one organization cannot affect another.
  • Sandbox / preflight environment for dangerous changes (SCP testing before production application).

Why it matters

The axis is load-bearing because IAM and consolidated billing and cross-account resource sharing do not traverse organization boundaries. Choosing multiple organizations is choosing to re-solve those problems at the cross-organization altitude (cross-account IAM between external accounts, separate billing, no shared VPC), which is operational overhead that scales with the number of organizations.

Conversely, choosing a single organization is choosing to rely on SCPs + OUs as the primary isolation mechanism — which is a policy boundary, not a structural boundary. A bug in SCP authoring, a mis-applied SCP, or a new AWS service that SCPs don't yet gate can leak across what the operator thought were isolated units.

The default recommendation from AWS:

"I recommend starting with a single organization and only considering multiple organizations when the isolation requirements outweigh the operational benefits of centralization." (patterns/start-single-organization-default)

Relationship to other isolation concepts

Axis Boundary Primary driver Typical account count
concepts/aws-partition Hard (cross-partition primitives don't exist) Sovereignty / jurisdiction Mandatory per partition
Single-vs-multiple-Organizations (this concept) Soft (duplicated mgmt surface) Regulatory BU / M&A / sandbox 1–5 typical
OU hierarchy within an org (concepts/organizational-unit) Policy (SCP inheritance) Workload-purpose / tenant segmentation 10–6000+
concepts/account-per-tenant-isolation Structural (AWS account) SaaS tenant isolation Proportional to tenant count
concepts/tenant-isolation App-level In-account multi-tenant SaaS 1 account

Seen in

  • sources/2026-05-11-aws-choosing-between-single-or-multiple-organizations — canonical disclosure of the decision axis with the ten-criterion trade-off table, the four use-case shapes per direction, and the AWS-recommended default posture. First wiki canonicalisation of the single-vs-multiple decision as an architectural choice distinct from the partition axis and the account-per-tenant axis.
Last updated · 542 distilled / 1,571 read