AWS Multi-Account Best Practices

Why more than one account

An AWS account is the strongest isolation boundary AWS offers. A person or a workload in one account has no access to another unless someone grants it. Each account has its own bill, so cost by account needs no tags. Each has its own service quotas. And a mistake or a compromise stays in the account where it happened.

AWS's guidance, Organizing Your AWS Environment Using Multiple Accounts, names the benefits:

Group workloads by purpose and owner, so each team knows what is theirs and what it costs.
Apply distinct controls by environment. Production gets the strictest policies; a sandbox gets room to experiment.
Constrain access to sensitive data to the few accounts that hold it, which is also what draws a clean SOC 2, HIPAA, or PCI DSS boundary.
Promote innovation in sandbox accounts that cannot reach production or the corporate network.
Manage costs by account, with budgets and alarms where the spending happens.
Distribute quotas, so one workload's growth never starves another.

The principles

From the same whitepaper:

Organize by function and by the controls a workload needs, not by the org chart. Reporting lines change more often than controls do.
Apply policies to organizational units (OUs), not to individual accounts. An account inherits its controls from where it sits.
Keep the management account for organization management and billing only. No workloads, and few people. Service control policies and resource control policies never apply to it, which is exactly why nothing else should run there.
Keep the OU tree shallow. AWS Control Tower governs nested OUs up to five levels deep; most organizations need two.
Start with the foundational OUs, Security and Infrastructure, and add the others as needs arise.

The target OU tree

These are the OUs AWS recommends in Recommended OUs and accounts. The purpose column is AWS's; the policy posture is our default.

OU	Purpose	Typical accounts	Policy posture (our default)
Security	The security services and the logs; foundational	Log Archive; Audit (the AWS Security Reference Architecture calls it Security Tooling); with Control Tower's backup integration, Central Backup and Backup Administrator	The strictest: only the security team, and the archive cannot be altered from any application account
Infrastructure	Shared infrastructure services; foundational	Network; Shared Services (directory, shared tooling)	Strict; changes only through the network or platform team's pipeline
Sandbox	Individual experimentation, disconnected from internal networks	One per developer or team	Budgets and alarms on every account; no connection to the corporate network or production; Regions limited
Workloads	Business applications	Prod and NonProd child OUs, one account per workload per environment	Production strictest; non-production a little looser so teams can move
Deployments	CI/CD tooling, kept apart from the workloads it deploys	Prod and non-prod pipeline accounts	Pipelines assume narrow roles into Workloads; no person holds standing write access
Policy Staging	Testing policy changes before they reach real accounts	Test accounts that mirror each policy pattern	Receives every new or changed policy first
Suspended	Accounts closed, or about to be	Accounts awaiting closure, or kept for records	Deny-all, except the break-glass role
Exceptions	Workloads that need an exception to the standard policies	As few as possible	Each exception named, owned, and reviewed
Transitional	A temporary home for accounts moving in from another organization or an acquisition	Accounts mid-move	The minimum guardrails that cannot break an incoming workload
Individual Business Users	Limited-access accounts for people who are not builders	Marketing, analytics, or finance users	A narrow allowlist of services

The target OU tree and core accounts. The management account sits outside every OU, and service control policies never apply to it, which is why it runs no workloads.

The core accounts

Account	What it holds
Management	AWS Organizations, billing, Control Tower, and IAM Identity Center's home unless it is delegated. No workloads.
Log Archive	The organization trail, AWS Config history, VPC Flow Logs, and Route 53 Resolver query logs: encrypted, versioned, and under Object Lock where retention requires. The AWS Security Reference Architecture also places Amazon Security Lake here.
Audit (Security Tooling)	The delegated administrator for GuardDuty, Security Hub, IAM Access Analyzer, Config aggregation, Inspector, Macie, and Detective, with cross-account read for the security team.
Network	Transit Gateway or Cloud WAN, IP address management, centralized egress and inspection, and Route 53 Resolver rules.
Shared Services	Directory services and shared tooling. Often the delegated administrator for IAM Identity Center.
Central Backup and Backup Administrator	The backup vault no workload account can touch, and the delegated AWS Backup administrator. Control Tower's backup integration places both in the Security OU.
Deployments	The pipelines, apart from the workloads they deploy.
Workload accounts	One per workload per environment, under Workloads/Prod and Workloads/NonProd.
Sandbox accounts	One per developer or team, with a budget.

Guardrails

Four layers, each with what it can and cannot do.

Service control policies (SCPs) set the maximum permissions for the IAM users and roles in member accounts. They grant nothing, they do not apply to the management account, and they do not restrict service-linked roles. Our baseline: deny leaving the organization; deny disabling or altering CloudTrail, Config, GuardDuty, Security Hub, and Access Analyzer; protect the Control Tower and security roles; deny member-account root actions; deny IAM user and access key creation outside the Exceptions OU; deny Regions outside the approved list, with global services excepted; and deny everything in Suspended.
Resource control policies (RCPs) set the maximum permissions on resources in member accounts, for the services that support them, among them Amazon S3, AWS STS, AWS KMS, Amazon SQS, and AWS Secrets Manager. With SCPs they form a data perimeter: only your identities, reaching only your resources, from expected networks. Our baseline: deny access to your resources from principals outside the organization, with AWS service principals excepted, and require TLS.
Declarative policies set a service's configuration across the organization and hold it as the service adds features. For Amazon EC2 today: block public access for VPCs, AMIs, and EBS snapshots; instance metadata defaults (IMDSv2); serial console access; and allowed images.
Control Tower controls come in three kinds: preventive (built on SCPs, RCPs, and declarative policies), detective (AWS Config rules), and proactive (CloudFormation hooks that stop a non-compliant resource before it is created), each labeled mandatory, strongly recommended, or elective. Our default: every mandatory and strongly recommended control, plus the elective controls your compliance framework needs.

How we roll them out. Every policy goes to Policy Staging first, then OU by OU: Sandbox, then non-production, then production, never at the root on its first day. Each carries a break-glass exception, IAM Access Analyzer validates it, and CloudTrail is watched for access denied for a day after each attachment. Detaching the policy is the rollback, and it takes one call.

Identity

IAM Identity Center for every person, connected to your identity provider with automatic provisioning (SCIM). Permission sets by job function, assigned to groups, never to individuals, with short sessions for the privileged ones. No IAM users for people, and no long-lived access keys for workloads: roles everywhere. Break-glass access that is tested and alarmed. Centralized root access, with member-account root credentials removed and the management account's root user on hardware MFA in separate custody. Temporary elevated access for production changes.

Logging and detection

One organization trail, in every Region, with log file validation, into Log Archive. AWS Config recording in every account and Region, aggregated in Audit. VPC Flow Logs and Route 53 Resolver query logs centralized. GuardDuty, Security Hub, and IAM Access Analyzer delegated to Audit, with every new account enrolled automatically. Findings routed to whoever is on call, and retention set by your compliance framework.

Network

A Network account owns shared connectivity, Transit Gateway or Cloud WAN, shared to the workload OUs through AWS RAM. VPC IP Address Manager is delegated to Network, with pools by OU and Region so address ranges never overlap. Egress and inspection (NAT gateways and AWS Network Firewall) are centralized where the traffic justifies it. Route 53 Resolver endpoints and rules are shared from Network. VPC Block Public Access is held by a declarative policy, and Sandbox stays off the corporate network. AWS's guide is Building a Scalable and Secure Multi-VPC AWS Network Infrastructure.

Backup

Backup policies attached to OUs from the organization. A delegated Backup Administrator account. Copies to a central vault in a separate account, Central Backup, so a compromised workload account cannot delete its own recovery points (cross-account management). Vault lock in compliance mode, or a logically air-gapped vault, where the retention rules require it. And restore testing on a schedule, because an untested backup is a hope.

Account vending

Every account comes from one path, never by hand: Control Tower Account Factory, with blueprints for customization; Account Factory for Terraform, where an account request is a pull request; Customizations for Control Tower; or Landing Zone Accelerator on AWS's account configuration. Each new account arrives in its OU with its baseline, its alternate contacts, its root email on your domain, its budget, and its service quotas from a Service Quotas organization template. A request process your platform team owns, a ticket or a pull request, sits in front of it.

Tagging and cost allocation

A small set of required keys, for example owner, cost-center, environment, application, and data-classification. A tag policy that standardizes key case and allowed values, enforced for the resource types that matter. Requiring a tag to exist at creation is a different tool, an SCP with request-tag conditions or a proactive control, applied with care. Cost allocation tags activated in the payer. And the account itself as the first cost boundary, so the bill is readable before anyone tags anything. AWS's guide is Best Practices for Tagging AWS Resources.

How we get there

Most organizations do not start from nothing. Either the existing organization is sound to keep, and we retrofit it: Control Tower set up or upgraded in place, the missing OUs and core accounts created, and every account moved into its target OU and enrolled. Or it is not, because the management account runs production, the organization belongs to someone else, or two must become one, and we move the accounts into a new organization, in waves through the Transitional OU.

Each path carries risks, and each has a handling: billing history and cost data stay with the old payer, so they are archived first; commitments and credits stay with the account that bought them, so owners and users move together or the old management account joins as a member; Marketplace private offers and support plans follow the payer, so vendors and AWS Support hear first; quotas reset on new accounts, so an organization template sets them; an account leaving an organization needs its own support plan, contact details, and payment method, so those are completed before its wave; policies that name the organization ID break on a move, so a pre-flight scan finds every one; root email and MFA must be in your custody, so they move to aliases you control; and a new policy can stop production, so it goes through Policy Staging first. The AWS Multi-Account Foundation is the fixed-price engagement that does this, in two weeks or six.

Where our defaults differ from AWS's

AWS often offers several good options. Where we pick one, here is which, and why.

IAM Identity Center's delegated administrator goes in Shared Services, not the management account, so the people who manage access do not need to be in the account that can change the organization.
No SCP is attached at the root on its first day. AWS allows it; we prove each policy in Policy Staging and attach it OU by OU, because a wrong condition at the root stops every account at once.
Account Factory for Terraform when you already run Terraform, and Account Factory with Customizations for Control Tower when you do not, so account requests live in the tool your platform team already reviews.
Every mandatory and strongly recommended Control Tower control, not every control. Elective controls go on when your compliance framework asks for them, so each one has a reason.
Landing Zone Accelerator only where Control Tower cannot be used, such as a Region it does not govern that you need. Control Tower is the default because it governs the accounts you vend next.

Sources

Every source below is AWS's own documentation, and each was read on the date at the top of this list. Where AWS's guidance changes, this page follows it.

Read on October 18, 2026; each page returned HTTP 200 that day.