ADR-0001: Account per workload per environment, in AWS's recommended OUs
- Status: Accepted (worked example)
- Date: 2026-10-23
- Deciders: Platform architecture, security, two product-team representatives (advice process)
Context and Problem Statement
Section titled “Context and Problem Statement”About 40 product teams will run workloads on AWS. We need an account structure that isolates workloads, lets us apply security policies at scale, and lets teams get new environments without tickets. The structure is hard to change later: moving accounts between OUs changes which policies apply, and restructuring affects every team.
How should we organise AWS accounts and organisational units (OUs)?
Decision Drivers
Section titled “Decision Drivers”- Security and auditability: strong isolation between workloads and environments; policies applied centrally.
- Self-service: a team can get a new account quickly without manual steps.
- Evolvability: the structure should grow (more teams, an EU expansion) without being redesigned.
- Blast radius: a mistake in one workload shouldn’t affect others.
- Cost visibility per team and workload.
Considered Options
Section titled “Considered Options”- Few shared accounts (for example, one each for prod, non-prod, and shared services), with isolation by VPC and IAM.
- One account per team, with all of that team’s environments inside it.
- One account per workload per environment, grouped into AWS’s recommended OUs, provisioned through Control Tower’s Account Factory.
Decision Outcome
Section titled “Decision Outcome”Chosen option: 3, one account per workload per environment, because the account is AWS’s strongest isolation boundary and the unit that SCPs, billing, and quotas apply to. It’s the only option that supports all three drivers at once.
Initial OU structure, following the AWS whitepaper’s advice to start with a subset of the recommended OUs and add more as needed:
| OU | Contains |
|---|---|
| Security | Log archive and security tooling (audit) accounts |
| Infrastructure | Shared networking and shared services accounts |
| Workloads → Prod, Non-prod | One account per workload per environment |
| Sandbox | Individual experimentation accounts with spending limits and no production connectivity |
The management account runs no workloads.
Consequences
Section titled “Consequences”- Good: Strong isolation and small blast radius. SCPs can differ between prod and non-prod.
- Good: Cost and ownership per workload come directly from the account.
- Good: New OUs (for example Policy Staging or Suspended) can be added later without moving workloads.
- Bad: Many accounts (likely 100+). Without automation, this is unmanageable, so Account Factory and baselines are mandatory, not optional.
- Bad: Cross-account access (networking, events, shared data) needs deliberate design. See ADR-0002 and ADR-0003.
Confirmation
Section titled “Confirmation”Fitness functions that check this decision is followed:
- No resources other than organisation-level services in the management account (AWS Config / CloudTrail review).
- Every account sits in one of the defined OUs; none at the root.
- A new workload account with baseline controls is provisioned in under one hour with no manual tickets (measured from Account Factory).
- Every account has
ownerandcost-centretags (tag policies). - New or changed SCPs are tested against a staging OU before reaching Workloads.
Pros and Cons of the Options
Section titled “Pros and Cons of the Options”1. Few shared accounts
Section titled “1. Few shared accounts”- Good: Simple to start; few accounts to manage.
- Bad: Weak isolation: one IAM mistake can expose many workloads.
- Bad: Shared quotas and noisy neighbours; cost attribution needs perfect tagging.
- Bad: Very hard to split later, so it fails evolvability.
2. One account per team
Section titled “2. One account per team”- Good: Clear ownership; fewer accounts than option 3.
- Bad: Prod and non-prod share an account, so policies can’t differ by environment.
- Bad: Team reorganisations force account migrations (Conway’s law in reverse).
3. Account per workload per environment
Section titled “3. Account per workload per environment”- Good: Strongest isolation; policies by environment; clean cost attribution.
- Good: Matches AWS’s own recommended structure.
- Bad: Highest account count; depends on automation.
More Information
Section titled “More Information”Revisit when:
- the EU expansion needs data-residency rules that differ from the rest of the organisation (consider an OU per jurisdiction under Workloads);
- account provisioning time rises above one hour, or teams start sharing accounts to avoid provisioning;
- AWS’s recommended OU guidance changes significantly.
Related: ADR-0002, ADR-0004, evolving a cloud platform.
Sources: AWS whitepaper Organizing Your AWS Environment Using Multiple Accounts: Recommended OUs and accounts and Production starter organization.