Designing a Multi-Account AWS Organization for Regulated Workloads

Regulated workloads do not belong in a single, sprawling AWS account. If you care about HIPAA, SOC 2, PCI-DSS, CJIS, FedRAMP, or equivalent, a multi-account AWS Organization is not a “nice to have”; it’s table stakes.

This walkthrough lays out a concrete way to design a multi-account AWS Organization for regulated workloads: the principles, the account/OU layout, the guardrails, and a phased implementation path.

1. Why multi-account for regulated workloads?

Putting everything in one or two accounts creates problems:

  • No clean blast-radius boundaries
  • Hard to prove least privilege and separation of duties
  • No clear line between regulated and non-regulated data
  • Auditors see a tangle of workloads, roles, and policies

A well-designed multi-account org gives you:

  • Isolation by design – Accounts are hard security boundaries. A mistake in one app doesn’t automatically compromise everything.
  • Regulatory scoping – “These accounts hold PHI/PCI/CJI; these do not.”
  • Cleaner audit story – Dedicated security/logging accounts, SCPs, consistent baseline.
  • Safer experimentation – Sandboxes that can’t touch regulated data.

2. Core building blocks in AWS

Before layout, understand the main pieces you’ll use.

AWS Organizations

Centralized management of accounts, OUs, and SCPs.
One management account (formerly master) that owns the org.

Organizational Units (OUs)

Hierarchical groups of accounts.
SCPs attach here to enforce global rules.

Service Control Policies (SCPs)

Guardrails. They define what cannot be done, even by admins in member accounts.

AWS Control Tower (optional)

Opinionated landing zone service.
Automates creation of core accounts, guardrails, and some logging.
Good if you want standardization and are okay with its conventions.

Core security services (usually centralized)

AWS CloudTrail, AWS Config, Security Hub, GuardDuty, IAM Identity Center, etc.

You’re designing how all of these come together to serve regulated workloads without choking developer productivity.

3. Reference OU structure for regulated workloads

Start from the top and work down. A reasonable, practical structure:

Root
├─ Core
│   ├─ Security
│   ├─ Logging
│   └─ Shared-Services
├─ Regulated
│   ├─ Regulated-Prod
│   └─ Regulated-NonProd
├─ NonRegulated
│   ├─ NonReg-Prod
│   └─ NonReg-NonProd
└─ Sandboxes

3.1 Core OU

Holds accounts that underpin everything:

  • Security Account – Security tooling, central Security Hub, GuardDuty master, cross-account access for security team.
  • Logging (Log Archive) Account – Centralized S3 buckets for CloudTrail, Config, and other immutable logs.
  • Shared-Services Account – Shared networking (Transit Gateway, central DNS), directory/identity integration, maybe central jump boxes, bastions, or shared tooling.

These accounts are highly locked down. Very few humans should have write access.

3.2 Regulated OU

This is the heart of your regulated effort:

  • Regulated-Prod OU
    Application accounts hosting production workloads subject to regulations (PHI, PCI, etc.).
  • Regulated-NonProd OU
    Dev, test, QA/UAT accounts where regulated code runs, but ideally without production data.

You can go further and split per domain:

Regulated-Prod
├─ Clinical-Prod
├─ Billing-Prod
└─ Analytics-Prod

The goal: each regulated system has one or more dedicated accounts. No multi-tenant “everything lives here” accounts for regulated workloads.

3.3 NonRegulated OU

Contains workloads not in regulatory scope:

  • Internal tools, public sites, marketing assets, etc.
  • Still needs security and governance, but with slightly more relaxed controls where appropriate.

3.4 Sandboxes OU

Least-trusted OU.

  • Time-bounded accounts for experimentation, POCs, training.
  • Aggressive SCPs to stop data exfiltration and connection into regulated networks.
  • If a dev wants to test something risky, it happens here, not in regulated OUs.

4. Recommended account types

Within those OUs, define standard account roles. At minimum:

Management Account

  • Hosts AWS Organizations.
  • Billing, consolidated reservations, enterprise agreements.
  • Do not run workloads here. Think “billing and governance only.”

Security Account (Core/Security OU)

  • Aggregated Security Hub, GuardDuty, Detective, etc.
  • Central automation (e.g., auto-remediation lambdas) that act across accounts.
  • Read access to logs in the Logging account.

Logging / Audit Account (Core/Logging OU)

Central S3 buckets for:

  • Organization-level CloudTrail
  • Organization AWS Config
  • Application logs replicated from other accounts, if required

Strongly restricted write access (only log delivery roles), virtually no delete permissions.

Shared-Services Account (Core/Shared-Services OU)

  • Shared networking primitives (Transit Gateway, central VPC for shared services).
  • Central DNS (Route 53), AD Connect / Directory integration, common tools.

Workload Accounts (Regulated / NonRegulated OUs)

Per system or product:

  • appname-dev
  • appname-test
  • appname-prod

Each with VPCs, services, and IAM scoped to that one app.

Sandbox Accounts (Sandboxes OU)

  • Named per team or per user group.
  • Auto-cleanup and aggressive cost and risk guardrails.

5. SCP strategy and guardrails

SCPs are where you enforce non-negotiable rules. Examples that are especially relevant for regulated workloads:

5.1 Global baseline SCPs (applied high in the tree)

  • Deny use of root user except specific support actions (if any).
  • Deny creation of long-lived access keys for root or break-glass roles.
  • Deny disabling CloudTrail or AWS Config.
  • Deny leaving the organization / disabling guardrails.
  • Restrict allowed regions to your approved list.
  • Deny attaching policies that allow *:* (full admin) where you don’t explicitly need it.

5.2 Regulated OU-specific SCPs

  • Deny public S3 buckets and public object ACLs.
  • Deny disabling encryption at rest on key services (S3, RDS, EBS, etc.).
  • Deny use of services you do not want in scope (e.g., certain AI services, unapproved storage).
  • Deny direct internet-facing resources unless behind approved ingress (ALB, API Gateway, WAF, specific VPC endpoints).

5.3 Sandbox OU SCPs

  • Deny connectivity back into Regulated OUs (no peering, no TGW attachments).
  • Deny data transfer to specific highly sensitive buckets or accounts.
  • Optionally, deny creation of certain expensive or risky services.

The SCP design should be codified in IaC (Terraform/CloudFormation/CDK) and peer-reviewed. This is not something to build by ad-hoc clicking in the console.

6. Networking patterns for regulated workloads

For regulated workloads, sloppy networking is a direct compliance and risk problem.

A common, workable pattern:

Centralized networking in Shared-Services

  • Transit Gateway or hub VPC.
  • Central egress (NAT, inspection, proxies).
  • Central ingress (WAF, shared load balancer layer, API gateway).

Spoke VPCs in each workload account

  • One or more VPCs per account, attached to the central hub.
  • Strict routing:
    • Only specific subnets can access internet.
    • East–west traffic between workloads is controlled and logged.

Private connectivity to sensitive stores

  • PrivateLink endpoints or VPC endpoints for services like S3, DynamoDB, etc.
  • No direct public access to data buckets holding regulated data.

Segregate regulated vs non-regulated networks

Even at the TGW/VPC level, treat regulated VPCs differently:

  • More monitoring
  • More restrictive routing
  • Tighter egress rules

If you can’t explain your network paths on a single diagram, it’s already too complex.

7. Identity and access design

Identity is where regulated environments usually fail. Keep it boring and clean.

Use a central IdP and AWS IAM Identity Center (SSO)

  • Users authenticate via your IdP (e.g., Entra ID, Okta, etc.).
  • Permission sets map users/groups → roles in accounts, not long-lived IAM users.

Define standard roles per account

  • Admin, PowerUser, ReadOnly, SecurityReadOnly, etc.
  • Same naming and permission boundaries across accounts.

Separation of duties

  • Security team roles: read-only everywhere, with elevated access only for incident response or specific tasks.
  • Dev team: admin in dev/test, constrained roles in prod.
  • Ops: scoped admin for infrastructure, not full org-change capabilities.

No IAM users for humans

  • If you must have them (legacy), treat them as technical debt and phase them out.
  • Force MFA and device compliance where possible.

For auditors, the story becomes simple: “All humans come through the IdP, mapped to specific roles, with logging at both IdP and AWS layers.”

8. Logging, monitoring, and auditability

For regulated workloads, logs are not optional, and they’re not “just turn on CloudTrail.”

CloudTrail

  • Organization trail that sends logs to the Logging account.
  • Multi-region, management and data events for critical services.
  • No account can disable it because of SCPs.

AWS Config

  • Organization-level aggregator in the Logging or Security account.
  • Rules enforcing encryption, backups, network rules, etc.

Security Hub / GuardDuty

  • Centrally managed in the Security account, delegated admin.
  • Findings from member accounts roll up for centralized triage.

Application Logs

  • Standardized approach: CloudWatch Logs → Kinesis/Firehose → SIEM or central log store.
  • Regulated logs stored in compliant, WORM-like configuration if required.

Evidence for audits

Be intentional about what you’ll show an auditor:

  • Diagrams of OU/account structure
  • SCPs (with rationale)
  • CloudTrail and Config configuration
  • Sample access review and incident handling evidence

9. Phased implementation plan

Trying to “rebuild everything at once” is how organizations stall. Use a phased approach.

Phase 0 – Requirements and classification

  • Identify which workloads are regulated and with which frameworks (HIPAA, PCI, etc.).
  • Classify data types and criticality.
  • Decide region footprint.

Phase 1 – Foundation and core accounts

  • Create AWS Organization (if not already).
  • Stand up and harden:
    • Security account
    • Logging account
    • Shared-Services account
  • Implement baseline SCPs at root/Core OUs.

Phase 2 – Identity & networking

  • Integrate central IdP with AWS IAM Identity Center.
  • Define and roll out standard permission sets.
  • Build central networking in Shared-Services.
  • Define network patterns for regulated vs non-regulated workloads.

Phase 3 – Regulated OU and workload accounts

  • Create Regulated-Prod and Regulated-NonProd OUs.
  • Attach stricter SCPs.
  • Create workload accounts per system/environment (starting with high-risk/high-value ones).
  • Deploy landing zone baseline (logging, Config, security agents) to each.

Phase 4 – Migration and decommissioning

  • Migrate workloads account-by-account.
  • Decommission legacy “kitchen sink” accounts as you go.
  • Update documentation and diagrams to reflect the new reality.

Phase 5 – Optimization and evidence

  • Fine-tune SCPs to remove unnecessary friction.
  • Implement regular access reviews and config drift checks.
  • Package architecture and control descriptions for audits and customer due diligence.

10. Common mistakes to avoid

  • Putting production and non-production regulated workloads in the same account.
    That’s a direct hit to blast-radius isolation and compliance scoping.
  • Letting developers run wild in the Regulated OUs.
    Give them freedom in Sandboxes and NonReg-NonProd. Regulated environments get rigor.
  • Treating SCPs as “we’ll do that later.”
    If you don’t lock things down early, you’ll build systems that depend on bad patterns.
  • Running workloads in the management account.
    This is an anti-pattern. Keep it clean and governance-focused.
  • Ignoring logs until an incident.
    If you don’t design logging and retention now, you’ll have nothing usable when you need it.
Tagged , , ,