Skip to content

SYSTEM Cited by 3 sources

AWS Organizations

What it is

AWS Organizations is the AWS service that manages multiple AWS accounts as a tree of organizational units (OUs), with policy inheritance (Service Control Policies / SCPs), consolidated billing, and centralized account lifecycle operations.

Per-partition Organizations topology

AWS Organizations is itself partition-scoped, which makes cross- partition architectures load-bearing on how you set up Organizations topology across partitions:

Partition pair Shape
Standard ↔ standard (same partition, cross-region) Single Organization; SCPs inherited normally
Standard ↔ GovCloud Paired-optional — GovCloud accounts can be invited into a commercial Organization (via AWS GovCloud invite flow), or operated as a separate Organization
Standard ↔ European Sovereign Cloud Mandatory separate Organization — cannot be paired
Standard ↔ GovCloud when sovereign-standalone is the goal Separate recommended — "failing over to an AWS European Sovereign Cloud-only state is simpler if the AWS Organizations setup is separate from the start" (Source: sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty)

"This doesn't require starting from scratch. Instead, you can manage the same organizational units (OUs) and policies for the AWS European Sovereign Cloud by reusing your existing deployment automation."

Tooling gap across sovereign partitions

"AWS Control Tower can't directly manage AWS GovCloud (US) or AWS European Sovereign Cloud accounts" (Source: sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty). Also: "limited availability of some AWS Organizations features in these partitions."

Governance parity across partitions requires hand-built automation that replicates OU structure + SCP hierarchy separately per sovereign Organization.

Billing

"Consolidated billing can be managed through Organizations" — applies within a partition. Cross-partition consolidated billing is not a feature; each Organization has its own bill.

See concepts/consolidated-billing-volume-discount for the economic-pull-toward-single-organization framing: AWS pricing tiers (S3 storage, data-transfer-out, Savings Plans pooling) aggregate within one organization; splitting into multiple organizations restarts each tier at the bottom for each payer.

Single-vs-multiple-Organizations topology

The third architectural-decision axis on AWS Organizations topology (alongside the cross-partition shape and the account-per-tenant shape): single organization with OU hierarchy vs multiple organizations as parallel governance domains.

The 2026-05-11 source (Source: sources/2026-05-11-aws-choosing-between-single-or-multiple-organizations) frames this as a choice between operational efficiency and risk isolation and comes down on a specific default: "I recommend starting with a single organization and only considering multiple organizations when the isolation requirements outweigh the operational benefits of centralization" — canonicalised as patterns/start-single-organization-default.

Named use cases that push toward single:

  • Centralized visibility and governance across accounts.
  • Shared corporate security policy across business units.
  • Consolidated billing with volume discounts.
  • Resource sharing (VPCs, AMIs, directory services) across accounts.
  • Centralized compliance enforcement via SCPs, AWS Config, and AWS Security Hub.

Named use cases that push toward multiple:

  • Independent business units with separate leadership and governance (subsidiaries, franchises) — canonicalised as patterns/separate-organization-per-regulated-division.
  • Regulated industries with legally-required entity segmentation (banking, insurance, healthcare).
  • M&A integration where newly-acquired companies keep their existing footprint.
  • Maximum blast-radius containment between business units.
  • Sandbox / preflight environment for dangerous governance changes — canonicalised as patterns/sandbox-organization-for-scp-testing. A non- regulatory reason to run a second organization whose only purpose is to test SCPs + OU restructurings before production application.

Ten-criterion trade-off table (per Source ibid):

Criterion Single organization Multiple organizations
Billing Consolidated billing with volume discounts Independent billing; no cross-organization discounts
Governance Centralized SCPs Each org defines its own policies
Security isolation Shared perimeter; SCPs apply globally Strong isolation between organizations
Access management Central IAM + cross-account No built-in cross-organization access
Scalability Thousands of accounts within one org Each org scales independently
Resource sharing Easy VPC / AMI / etc. sharing within org No built-in sharing between orgs
Operational overhead Lower; centralized governance Higher; duplicated per org
Compliance and audit Centralized CloudTrail / Config across accounts Separate audit trails per org
Risk isolation Misconfigurations could impact accounts Contained within individual orgs
Flexibility Standardized controls Each org tailors controls

Relationship to other topology axes:

Axis Within-organization mechanism Cross-organization mechanism
Workload-purpose separation OUs + SCPs (patterns/multi-account-isolation) Separate organizations
SaaS tenant isolation Account-per-OU, concepts/account-per-tenant-isolation at ~6,000 accounts in one org Never — tenant-per-org not a standard shape
Regulatory mandate OU + strict SCP (for policy-level compliance) Separate organization (for legally-mandated entity segmentation)
Sovereignty / jurisdiction N/A — partition-scoped Separate organization per partition (mandatory for European Sovereign Cloud, optional for GovCloud)

Four-step governance model

AWS's canonical multi-account-management flow (Source: sources/2026-05-11-aws-choosing-between-single-or-multiple-organizations):

  1. Add accounts — create new accounts or invite existing accounts into the organization.
  2. Group accounts into organizational units (OUs) by use-case or workstream.
  3. Apply policies — SCPs (permission boundaries), Backup Policies, Tag Policies, AI Services Opt-out Policies, etc., attached to OUs or accounts. Policies inherit down the OU tree; effective ceiling at any account is the intersection of all policies in its path.
  4. Enable AWS services integrated with AWS Organizations (Config, Security Hub, CloudTrail, Backup, GuardDuty, and dozens of others).

Stub page

Seen in

  • sources/2026-05-11-aws-choosing-between-single-or-multiple-organizations — canonical disclosure of the single-vs-multiple-Organizations decision axis with AWS's recommended default posture (start single; only split when isolation outweighs centralization), the ten-criterion trade-off table, and the four use-case shapes that justify deviation — regulated-industry entity segmentation, M&A, subsidiary autonomy, and sandbox-organization for SCP preflight. First wiki canonicalisation of the start-single- default posture and of the non-regulatory-reason sandbox- organization-for-SCP-testing pattern. Also first explicit disclosure of the four-step governance model (add accounts → group into OUs → apply policies → enable services).
  • sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty — canonical reference for the per-partition Organizations topology, the GovCloud-vs-Sovereign-Cloud pairing asymmetry, and the Control Tower management gap.
  • sources/2026-02-25-aws-6000-accounts-three-people-one-platform — the SaaS-tenant-level application of AWS Organizations: ProGlove uses Organizations + SCPs + StackSets as the fabric for ~6,000 tenant accounts under a 3-person platform team. Explicit call-out that "although multi-account strategies are common at the enterprise level, adopting them at the SaaS tenant level is less common. Patterns, tooling, and reference architectures are still evolving, which means building custom solutions becomes necessary." Organizations is the load-bearing primitive for OU-scoped policy inheritance, consolidated billing (per-tenant cost attribution via Cost Explorer), and tag policies used to enforce telemetry-tagging discipline (patterns/central-telemetry-aggregation).
Last updated · 542 distilled / 1,571 read