How to Design a Multi-Account AWS Architecture

I’ve helped dozens of organizations move from a single AWS account to a multi-account architecture, and the ones that planned their OU hierarchy before provisioning accounts always scaled more smoothly. The account structure you design today dictates your blast radius, billing model, and permission boundaries for the next three years. This guide walks through the principles that make scaling painless.

Start with Your OU Hierarchy, Not Accounts

The biggest mistake I see is designing OUs around an org chart instead of around policy application. Think policy-first. Every AWS Organization Control Policy (SCP) you write applies to an entire OU and all its accounts. If your team structure changes but your policy structure doesn’t, you end up with conflicting governance.

Design your top-level OUs around control domains, not teams. A typical structure looks like:

• Security — accounts for logging, security tooling, audit
• Infrastructure — shared services: DNS, networking, directory services
• Workloads — application environments
• Sandbox — experimentation, no production data
• Suspended — accounts being decommissioned, SCPs deny all actions

Under Workloads, create sub-OUs for environment tiers or business units:

Workloads/
  ├── Development
  ├── Testing
  ├── Staging
  └── Production

Or, if you have multiple lines of business:

Workloads/
  ├── PaymentServices/
  │   ├── Development
  │   ├── Staging
  │   └── Production
  └── Analytics/
      ├── Development
      └── Production

This structure makes it simple to apply environment-specific SCPs (e.g., “prod accounts must enforce encryption”) without touching dev accounts.

Decide Your Account Granularity

How many accounts do you actually need? The rule of thumb: one account per workload per environment. Benefits:

• Blast radius isolation: A security incident in the dev app doesn’t cascade to production
• Separate billing: Chargeback per business unit is straightforward
• Permission boundaries: IAM in account A cannot affect resources in account B
• Compliance: Easier to audit and isolate regulated workloads (PCI, HIPAA)

A small team might start with fewer accounts (dev, staging, prod) and split into more as they grow. A large enterprise with 50 applications would have 150+ accounts easily (50 apps × 3 environments).

Note: AWS supports up to 10,000 accounts per organization. The limiting factor is usually operational complexity, not AWS quotas. Start conservatively and add accounts as your team matures.

Design Mandatory Accounts

Every healthy organization needs a set of foundational accounts regardless of size. These are never home to application workloads:

Provisioning these first, before any workload accounts, means your team is never caught off-guard by compliance requirements.

Plan Your Service Control Policies (SCPs)

SCPs are the guardrails that prevent accounts from doing dangerous things. Start with three layers:

Root-level SCPs (deny-list approach):

# Deny all actions outside approved regions
aws organizations put-policy \
  --content '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["us-east-1", "us-west-2"]
        }
      }
    }]
  }' \
  --type SERVICE_CONTROL_POLICY

Security OU SCPs:

• Deny leaving the organization (organizations:LeaveOrganization)
• Deny disabling CloudTrail or deleting trails
• Deny disabling Config
• Require MFA for root-level actions

Workloads OU SCPs:

• Deny creating IAM users (force IAM Identity Center)
• Require environment tags on all EC2, RDS, DynamoDB resources
• Deny unencrypted EBS volumes
• Enforce VPC Flow Logs on all VPCs

Sandbox OU SCPs:

• Deny certain expensive services (EC2 on-demand, RDS, Elasticsearch)
• Spending cap enforcement via Budgets (via Lambda, since SCPs can’t set limits)
• Auto-cleanup tags to delete resources older than 7 days

Design Your Network Topology

A hub-and-spoke topology using AWS Transit Gateway scales better than full-mesh VPC peering. Keep networking central in the Network account:

• Hub VPC: 10.0.0.0/16, hosts Transit Gateway, NAT Gateways, route summarization
• Spoke VPCs (one per workload account): 10.x.0.0/16 ranges, attach to TGW
• Egress VPC: Dedicated VPC for internet-bound traffic, all outbound NAT flows through one account for logging
• VPC Sharing: Use AWS Resource Access Manager (RAM) to share subnets from the hub into spoke accounts without peering

This model simplifies routing, centralizes security monitoring (all egress funnels through one NAT), and avoids the complexity of meshed peering relationships.

# List Transit Gateway attachments to verify spoke connectivity
aws ec2 describe-transit-gateway-attachments --region us-east-1

Plan Your Tagging Taxonomy

Tagging is the foundation of cost allocation, automation, and governance. Define mandatory tags and enforce them with SCPs:

Required Tags:

• Environment: dev

  test

  staging

  prod

• Owner: email or team name
• CostCenter: internal cost tracking code
• Application: app name or service name

• DataClassification: public

  internal

  confidential

  restricted

Require these on EC2, RDS, S3, DynamoDB, and Lambda:

aws organizations put-policy \
  --content '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Deny",
      "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:RequestTag/Environment": "true"
        }
      }
    }]
  }' \
  --type SERVICE_CONTROL_POLICY

Document Before You Build

Create an Account Register spreadsheet before provisioning:

This living document becomes your source of truth for access requests, permission assignments, and cost chargeback.

Is This Safe?

This is a design exercise—nothing is destructive. However, changing your OU structure after Control Tower enrollment requires re-enrolling affected accounts, which causes downtime for CloudFormation-managed baselines. Get stakeholder buy-in before implementation.

Key Takeaway

A well-designed multi-account architecture is your foundation for scaling securely. Start with a policy-first OU hierarchy, assign accounts by workload and environment, and enforce governance with SCPs and tagging. The upfront planning pays dividends when you’re managing 100+ accounts across your organization.

Questions? Connect with me on LinkedIn.