Skip to content

AWS 2026-05-11 Tier 1

Read original ↗

AWS — Choosing between single or multiple organizations in AWS Organizations

Summary

Short AWS Architecture Blog decision-framework post (2026-05-11) that distills a cloud-migration advisor's customer conversations into an explicit rubric for when to run a single AWS Organization vs when to run multiple. The post lays out ten decision criteria across a trade-off table, enumerates the scenarios that push each direction, and closes with the AWS- recommended default: start with a single organization and only consider multiple organizations when isolation requirements outweigh the operational benefits of centralization.

Key takeaways

  • Default posture is single organization. "Most AWS customers adopt a single organization and create multiple accounts within it." AWS's explicit recommendation: "I recommend starting with a single organization and only considering multiple organizations when the isolation requirements outweigh the operational benefits of centralization." This is canonicalised as patterns/start-single-organization-default.

  • The core tension is operational efficiency vs risk isolation. "When deciding between using single or multiple organizations, enterprises must balance operational efficiency with risk isolation. A single organization provides simplified management, volume discounts, and easier resource sharing and governance. Structuring the enterprise with multiple organizations means stronger security and failure isolation, greater governance flexibility, and better support for organizational autonomy." Canonicalised as concepts/operational-efficiency-vs-risk-isolation-tradeoff.

  • Four single-organization use cases named. "(1) centralized visibility and governance across AWS accounts; (2) teams and business units operate under a shared corporate security policy; (3) consolidate billing and optimize for volume discounts; (4) share resources (such as networking or directory services) between accounts; (5) centralized compliance enforcement using SCPs, AWS Config, and AWS Security Hub." The worked example — "a large global retailer with regional teams and application owners … each team creates their own AWS accounts under a central IT governance framework. A core team is responsible for centrally managing regulatory and security standards across the entire company."

  • Four multiple-organization use cases named. "(1) independent business units with separate leadership, governance, and security requirements (for example, subsidiaries or franchises); (2) regulated industry where strict segmentation between entities is legally required (for example, banking or healthcare); (3) managing mergers and acquisitions, where newly acquired companies maintain their existing AWS footprint; (4) maximum isolation of the potential impact of issues, so that misconfigurations, security incidents, or policy changes in one organization don't affect others." The regulated-finance worked example — "a multinational financial services company with distinct retail banking, investment banking, and insurance divisions. Each division has its own regulatory body and distinct security requirements, so they each manage their own organization." Canonicalised as patterns/separate-organization-per-regulated-division.

  • Sandbox organization for SCP testing named as a load-bearing use case: "a global software company that uses a separate organization as a sandbox to develop and test guardrails and SCPs prior to applying them to their primary organization." Canonicalised as patterns/sandbox-organization-for-scp-testing — a distinct reason to run a second organization that has nothing to do with regulatory segregation or M&A.

  • Ten-criterion trade-off table disclosed. Billing, governance, security isolation, access management, scalability, resource sharing, operational overhead, compliance and audit, risk isolation, flexibility. Each row makes explicit what a single organization provides that a multi-organization topology cannot, and vice versa — the rubric for matching architectural shape to isolation requirement.

  • Consolidated billing with volume discounts is the load-bearing economic pull toward single-organization. "Consolidated billing with volume discounts across accounts" vs "Each organization has independent billing; no cross-organization discounts" — canonicalised as concepts/consolidated-billing-volume-discount. Any workload with material tiered-pricing spend (S3 storage, EC2 reserved instances, data transfer out) sees a direct per-dollar penalty for splitting into multiple organizations.

  • Resource sharing inside an organization is a first-class primitive; across organizations it isn't. "Easy sharing of VPCs, Amazon Machine Images (AMIs), and other resources within organization" vs "No built-in sharing between organizations". Shared services architectures (central networking, central directory, central logging) assume a single organization for practical deployment.

  • Cross-organization IAM has no built-in primitive. "Central IAM roles and cross-account access setup" vs "No built-in cross-organization access; fully independent IAM". Cross- organization access must be rebuilt as cross-account IAM between external accounts — a distinct problem from cross-partition auth but adjacent in shape.

  • AWS Organizations mechanics. "Add accounts. Create new accounts or invite existing accounts to your organization. Group accounts. Group accounts into organizational units (OUs) by use-case or workstream. Apply policies. Apply policies to accounts or OUs, such as service control policies (SCPs) which create permission boundaries. Enable AWS services. Enable AWS services integrated with AWS Organizations." Foundational four-step model for multi-account strategy.

Systems / concepts / patterns extracted

Systems (all pre-existing, extended):

  • systems/aws-organizations — the substrate of the whole post; extended with the third architectural-decision axis (single- vs-multiple, alongside cross-partition topology and account-per- tenant SaaS).
  • systems/aws-iam — called out as the load-bearing primitive that doesn't cross organization boundaries; similar hard- boundary property to the per-partition IAM framing.
  • systems/aws-config, systems/aws-security-hub — named as the centralised-compliance-enforcement substrate that benefits from single-organization scope.
  • systems/aws-cloudtrail — named as centralised-audit primitive that fragments under multiple organizations.
  • systems/amazon-vpc — named as one of the resource types shared trivially within an organization but not across organizations.

Concepts (mostly new):

Patterns (new):

Decision-criteria trade-off table (verbatim)

From the post, with expansion cross-references where applicable:

Criterion Single organization Multiple organizations
Billing Consolidated billing with volume discounts across accounts Each organization has independent billing; no cross-organization discounts
Governance Centralized SCPs and policies for accounts Each organization defines its own governance policies
Security isolation Shared security perimeter; SCPs apply globally Strong isolation between organizations
Access management Central systems/aws-iam roles and cross-account access setup No built-in cross-organization access; fully independent IAM
Scalability Supports thousands of accounts within a single organization Each organization is independent; you scale organizations separately
Resource sharing Easy sharing of VPCs, AMIs, and other resources within organization No built-in sharing between organizations
Operational overhead Lower; centralized governance reduces duplication Higher; governance, security, and operations duplicated per organization
Compliance and audit Centralized logging, systems/aws-cloudtrail, and systems/aws-config across accounts Requires separate audit trails per organization
Risk isolation Misconfigurations could impact accounts Misconfigurations are contained within individual organizations
Flexibility Standardized controls across accounts Each organization can tailor controls to its specific needs

Caveats

  • Prescriptive decision post, not a retrospective. No production numbers (account counts, tenant counts, cost-delta between single and multi-organization topologies), no customer case, no incident-driven forcing function.
  • No mention of cross-partition topology. This post is about multiple organizations within a partition; cross-partition shapes (concepts/aws-partition) have additional constraints orthogonal to the single-vs-multiple decision.
  • No treatment of account-per-tenant SaaS. The post's "multiple organizations" framing is about a handful of organizations for regulatory / M&A / sandbox reasons, not thousands of organizations for tenant isolation. Account-per-tenant SaaS (ProGlove at 6,000 accounts) uses a single organization with OU + tenant- account structure; that shape composes with this post's axis but is not the same decision.
  • No quantification of volume discounts. The post asserts consolidated billing delivers volume discounts but does not put numbers on it; for a given workload the cross-organization billing penalty depends on the specific AWS-service mix (S3 storage tiering, EC2 reserved-instance pooling, data-transfer- out pricing).
  • No discussion of migrating between shapes. The closing recommendation — "long-term benefits of consolidation often make a compelling case for eventual migration to a single organization" — is not mechanized. Organization-merge + account-migration mechanics are acknowledged as a problem but not walked through.
  • The sandbox-organization use case is a single example. The post names it but doesn't enumerate other "non-regulatory" reasons a company might run multiple organizations (e.g. dev-infrastructure organization for engineering-platform experimentation, partner-integration organization for third-party connections). The canonical-wiki pattern is framed broadly but the source disclosure is narrow.

Source

Last updated · 542 distilled / 1,571 read