Skip to content

PATTERN Cited by 1 source

Separate AWS Organization per regulated division

Intent

Run one AWS Organization per regulated business division, subsidiary, or newly-acquired company when the isolation requirement is legally mandated entity-level segmentation, or when organizational autonomy / distinct regulatory regimes make a shared-organization shape infeasible.

This is the regulated-industry / M&A / subsidiary deviation from the single-organization default. The governing principle: "When the isolation requirements outweigh the operational benefits of centralization, split." (Source: sources/2026-05-11-aws-choosing-between-single-or-multiple-organizations)

The source quotes

AWS names four scenarios where multiple organizations make sense:

"(1) You have independent business units with separate leadership, governance, and security requirements (for example, subsidiaries or franchises). (2) You're in a regulated industry where strict segmentation between entities is legally required (for example, banking or healthcare). (3) You're managing mergers and acquisitions, where newly acquired companies maintain their existing AWS footprint. (4) You want maximum isolation of the potential impact of issues, so that misconfigurations, security incidents, or policy changes in one organization don't affect others." (Source: sources/2026-05-11-aws-choosing-between-single-or-multiple-organizations)

The financial-services 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." (Source ibid)

Why the pattern is load-bearing

Three properties make the separate-organization shape structurally different from the OU-separation shape:

  1. IAM is fully independent. No shared trust surface across organizations — a compromised credential in one organization cannot be used to access resources in another. An OU boundary within one organization shares the organization's IAM namespace; a separate-organization boundary does not.
  2. Billing is fully independent. Each organization has its own payer account, its own consolidated bill. Useful when the regulated division must not share financial data / billing entities with other divisions; costly because volume discounts do not cross organization boundaries.
  3. Governance is fully independent. Each organization authors its own SCPs, enables its own services, applies its own Config rules, runs its own Security Hub instance. No risk of a central-IT policy change accidentally affecting a regulated division.

These three properties together make the pattern the only credible shape for legally-mandated entity segmentation — regulators typically cannot accept "we use SCPs to enforce this" when the law requires structural, not policy-level, separation.

Canonical use cases

Regulated financial services divisions

Multi-division financial services (retail banking + investment banking + insurance) where each division has a separate regulatory body. Each division runs its own organization; each organization's policy surface is tailored to that division's regulator.

Healthcare entities

Separate healthcare entities (hospital system + payer + life sciences R&D) where HIPAA BAA coverage + PHI segmentation requirements mandate entity separation. Shared services (employee email, identity) can still be operated centrally if appropriate BAAs are in place, but the clinical, claims, and R&D workloads live in separate organizations.

Post-M&A integration

A company acquires another company that has existing AWS infrastructure. Options:

  • Keep the acquired org as its own organization during integration (weeks to years) — operationally simplest, preserves the acquired team's pipelines / processes / compliance history.
  • Merge into the acquirer's organization eventually — typically months later, via account-migration tooling, after baseline policies are aligned.

The source frames M&A as a valid transient or permanent reason to run multiple organizations, with the long-term implication that most companies eventually consolidate:

"Although maintaining separate organizations might offer stronger isolation and customized governance in the short term, the long-term benefits of consolidation — including volume discounts, simplified resource sharing, and reduced operational overhead — often make a compelling case for eventual migration to a single organization." (Source ibid)

Subsidiaries with organizational autonomy

A multinational holding company whose subsidiaries operate independently under their own brands, their own IT leadership, and their own security policies. Forcing them into one organization would require central IT to impose policies across independent business entities — a shape the source acknowledges some enterprises reject on principle.

Maximum blast-radius containment

Where the cost of a shared-organization incident is catastrophic (not just painful), multiple organizations provide a structural containment primitive that SCPs cannot match:

"Strong isolation between organizations." (Source ibid, decision-criteria table)

A misconfiguration, security incident, or policy change in one organization has zero blast radius into a sibling organization. Inside one organization, SCPs + OUs provide policy-level blast- radius containment that can be defeated by authoring mistakes.

What the shape looks like

  • One Organization per division / subsidiary / acquired entity — each with its own management account, its own OU tree, its own SCPs, its own billing, its own identity integration.
  • Hub-and-spoke identity federation (optional) — a single enterprise IdP (Okta, Azure AD, AWS IAM Identity Center in a distinct "identity" organization or on-prem) can federate into each organization's IAM Identity Center instance; users get a unified SSO experience without sharing IAM across organizations.
  • Separate audit / compliance surfaces — each organization maintains its own CloudTrail aggregator, Config aggregator, Security Hub instance; a central SIEM can pull from each but does not have write-back authority.
  • Cross-organization access as cross-account IAM between external accounts — when a division genuinely needs to access a resource in another division, cross-account IAM roles with trust policies + external IDs are used, exactly as with any untrusted external AWS account. No implicit org-membership trust.
  • Per-organization infrastructure duplication — shared services (networking, directory, logging) are duplicated per organization if needed, or accessed via explicit PrivateLink / VPC peering across organizations.

Composition with other patterns

  • concepts/account-per-tenant-isolation — each division's organization can run its own account-per-tenant SaaS if applicable; the tenant-axis is orthogonal to the division-axis. A regulated subsidiary with SaaS tenants has each tenant as an account inside the subsidiary's organization.
  • Partition axis — composes cleanly with separate organizations per regulated division. European operations of a regulated US bank may live in an AWS European Sovereign Cloud organization for the European division, with a US-partition organization for the US division. (See concepts/aws-partition and sources/2026-01-30-aws-sovereign-failover-design-digital-sovereignty.)
  • patterns/sandbox-organization-for-scp-testing — each regulated organization can have its own sandbox organization for SCP preflight, bringing the total to 2N organizations (one prod + one sandbox per division) if the division's change cadence justifies it.

Caveats

  • Operational overhead scales with N. Every additional organization is another full set of: management account, identity integration, monitoring pipeline, audit aggregator, CI/CD pipeline, cost-reporting workflow. Two organizations is roughly ~1.8× the operational effort of one; five is ~4× or more.
  • Billing penalty is real. Each organization restarts AWS pricing tiers from the bottom; for consumption-heavy workloads this can add up. Model the billing impact before splitting.
  • Cross-organization tooling is DIY. StackSets, RAM, Observability Access Manager, CloudTrail organization-trail, Security Hub aggregation — all scoped to one organization. Cross-org tooling must be rebuilt from cross-account primitives.
  • Regulated-division framing is not a license to proliferate organizations. AWS's posture is only deviate from single when isolation outweighs centralization. If a company's compliance team wants separate organizations "to feel safer" without a specific regulatory requirement, the cost-benefit probably doesn't justify it — OUs + strict SCPs are usually sufficient.
  • Cross-organization user experience is harder. Users who need access to resources across divisions must authenticate to each organization's IdP integration, maintain cross-account roles, etc. Federation from a shared enterprise IdP mitigates the UX problem but doesn't eliminate the cross-organization access setup.
  • M&A transient-shape has migration cost. Keeping an acquired org as a separate organization is cheap short-term but expensive long-term; most M&A integrations eventually merge. Plan the migration path at the same time as deciding to keep it separate.

Seen in

Last updated · 542 distilled / 1,571 read