Build scalable AWS multi-account structures: Organisation, security, cost
A single AWS account accumulates problems as the organisation grows. Production and development workloads share IAM policies. A developer's experimental deployment can affect production networking. Cost allocation is a single tangled bill with no clear ownership per team. Security controls applied at the account level must account for every possible workload rather than being tuned to a specific environment.
Multi-account structures solve these problems by providing workload isolation at the account boundary, the strongest isolation available in AWS. This guide covers the design decisions that make a multi-account structure actually work: account grouping, OU design, policy enforcement, cost allocation, and automation.
Why accounts are the right isolation boundary
AWS accounts provide hard boundaries that IAM permissions cannot. An IAM permission denied in a single account still lives in the same blast radius as everything else in that account. A separate account means a misconfiguration in one workload cannot directly affect another, even if IAM is misconfigured.
Concrete benefits: - Security isolation: Compromised credentials in a development account cannot access production resources. IAM roles and policies are per-account. - Cost visibility: AWS billing is per-account. Separate accounts produce separate line items, enabling accurate chargeback and budget control without complex cost allocation tag schemes. - Compliance scope: PCI DSS, FCA, and GDPR compliance scope can be limited to specific accounts. Keeping cardholder data or personal data in a dedicated account restricts the audit scope rather than applying controls to every resource in the organisation. - Service limits: AWS service quotas are per-account. High-traffic production workloads do not compete with development workloads for the same quotas.
Design the account grouping
Structure accounts by function, not by your organisational chart. The organisational chart changes; functional grouping remains stable.
The foundational accounts every organisation needs:
Management account: AWS Organisations root. Used only for billing aggregation and Organisations management. No workloads run here. Root credentials must be tightly controlled.
Security account: Centralised security tooling. Amazon GuardDuty, AWS Security Hub, CloudTrail log aggregation, AWS Config, and Amazon Detective aggregation live here. Read access to all other accounts for security monitoring purposes.
Log archive account: Long-term retention for CloudTrail logs, Config records, and VPC Flow Logs. Separate from the Security account so that log archive retention is isolated from operational security tooling.
Network account: Shared networking infrastructure. Transit Gateway, Direct Connect connections, and shared VPCs live here. Acts as the hub in a hub-and-spoke network model.
Workload accounts: One or more accounts per major workload, split by environment (production, staging, development). The production account has the tightest controls; the development account allows more experimentation.
Sandbox account: Developer playground. No policies restricting experimentation. Completely isolated from production. Cleaned up periodically.
Organise accounts into OUs
AWS Organisations Organisational Units (OUs) provide the structure for applying Service Control Policies (SCPs) consistently. OUs inherit the SCPs of parent OUs.
A practical OU structure:
Root
├── Security OU
│ ├── Security account
│ └── Log Archive account
├── Infrastructure OU
│ └── Network account
├── Workloads OU
│ ├── Production OU
│ │ └── Production workload accounts
│ ├── Pre-Production OU
│ │ └── Staging accounts
│ └── Development OU
│ └── Development accounts
└── Sandbox OU
└── Developer sandbox accounts
Apply SCPs at the OU level, not the account level, where the same policy covers multiple accounts. For UK organisations, useful SCPs include: - Deny creation of resources outside eu-west-1 and eu-west-2 (data residency enforcement) - Deny disabling of CloudTrail (ensures audit trail is always active) - Deny root account API calls (forces use of IAM roles) - Require MFA for sensitive actions (enforced for production OU accounts)
Use Control Tower for governed account provisioning
Manually creating accounts with consistent baseline configuration does not scale. AWS Control Tower automates account provisioning with: - Baseline CloudTrail and Config enabled in every new account - Log aggregation to the Log Archive account configured automatically - Baseline SCPs applied per OU - IAM Identity Center configured for federated access
The Account Factory creates new accounts that conform to the baseline controls without manual configuration. When a new team needs a development environment, Account Factory provisions a compliant account in minutes.
For organisations already running AWS without Control Tower, a migration is possible but requires careful planning. The primary steps: enrol existing accounts into Control Tower's management, validate that baseline controls do not conflict with existing configurations, and enable drift detection.
Cost allocation across accounts
With separate accounts, consolidated billing in the management account aggregates all charges. Each account appears as a line item. This is basic cost visibility; for chargeback, you need tagging.
Apply consistent resource tags across all accounts:
CostCentre: maps to the internal department or productEnvironment: prod, staging, devOwner: team or individual responsibleProject: the workload or product
AWS Cost Explorer in the management account can break down costs by tag across the consolidated bill. Create separate budgets per account in AWS Budgets, configured to alert the relevant account owner when spend approaches the threshold.
For organisations using AWS Organisations with consolidated billing, Reserved Instance and Savings Plans benefits apply across accounts when purchased in the management account. This means a Reserved Instance purchased centrally reduces the on-demand cost for the matching instance type regardless of which member account is running it.
IAM Identity Center for cross-account access
Rather than managing IAM users in each account separately, use AWS IAM Identity Center (formerly AWS Single Sign-On) to provide federated access. Users authenticate once (via your identity provider: Active Directory, Okta, Google Workspace) and receive permission sets that map to IAM roles in specific accounts.
A developer accessing development accounts sees only the development accounts in their access portal. A production operations engineer has access only to production accounts with the appropriate role. No IAM users or access keys to manage per account.
Where Critical Cloud comes in
Multi-account AWS architecture is the foundation everything else builds on. Getting the OU structure, SCP design, and account baseline configuration right from the start is significantly easier than retrofitting it onto a sprawling single-account environment. We design and implement AWS multi-account structures for technology-led businesses, with account baseline automation, federated access, and centralised security monitoring in place from day one. As the world's first Powered by Datadog accredited partner, we extend observability across account boundaries so metrics, traces, and logs from every account appear in a single operational view. See how Critical Support works.