Multi-Account Strategy

A Multi-Account Strategy uses separate AWS accounts as security and billing boundaries. Each account isolates its resources, IAM principals, and network from other accounts. This is the strongest isolation mechanism in AWS, stronger than VPCs, subnets, or IAM policies.

Common Account Structure

• Management account: Organizations root, billing, SCPs (no workloads)
• Security account: centralized GuardDuty, Security Hub, CloudTrail
• Log archive account: centralized, immutable log storage
• Network account: Transit Gateway, shared VPCs, DNS
• Workload accounts: separate per environment (dev, staging, prod) or per team
• Sandbox accounts: experimentation with tight guardrails

Why the Account Boundary Is Different

Every other isolation mechanism in AWS shares a control plane with the thing it is isolating from. Two VPCs in one account are separated at the network layer, but a single IAM principal with ec2:* can peer them, modify both, or read data from either. Two subnets share the same security groups namespace. An account boundary is different: IAM principals, resource policies, service quotas, and the CloudTrail record all stop at the account line. Cross-account access has to be granted explicitly through a role trust policy or a resource-based policy, and that grant is visible and auditable.

This matters for practical numbers too. Quotas are per account, so a runaway workload cannot exhaust another team's Lambda concurrency or ENI limits. Blast radius from a compromised credential is bounded by what that account holds. And when you need to hand a workload to a different team or wind one down, an account is a clean unit to transfer or close.

Plan for the quotas: the default maximum number of accounts in an organization is 10, adjustable through Service Quotas, with increases granted up to 50,000 depending on the customer. Only the management account can submit that request, and an invitation sent to an account counts against the quota until it is accepted or declined. Organizations supports up to 2000 OUs, nested five levels deep under the single root.

How It Goes Wrong in Practice

The most expensive mistake is treating the multi-account structure as an org chart instead of a blast radius design. Teams create one account per team, which feels tidy, but then production and development for the same workload live in the same account. The isolation you actually wanted, keeping a developer's mistake away from production data, is gone. Environment separation should generally win over team separation: one account per workload per environment, with team ownership expressed through OUs and tags.

The second failure is the account that becomes a shared dumping ground. A "shared services" account starts with DNS and a CI runner, then acquires a monitoring stack, a bastion, a few internal APIs, and eventually credentials that reach every other account. Because everything in the org trusts it, that account becomes a single point of compromise with more effective privilege than the management account's SCP guardrails ever contemplated. Whenever an account holds a role that can assume roles in many other accounts, treat it as a tier-zero asset: no general developer access, strong MFA, tight CloudTrail alerting.

Third, teams underinvest in the account vending process. Manually created accounts drift: some have GuardDuty enabled, some do not, some have the log-forwarding role, some are missing it. Six months later nobody can answer "is CloudTrail on everywhere" without a script. Account creation should be automated from day one through Control Tower Account Factory or equivalent infrastructure as code, with the baseline security services enabled by Organizations-level delegated administration rather than per-account clicks.

Inventorying Accounts From the CLI

To list every account in the organization:

aws organizations list-accounts

No required parameters. Each account object includes Id, Arn, Email, Name, State (PENDING_ACTIVATION, ACTIVE, SUSPENDED, PENDING_CLOSURE, or CLOSED), JoinedMethod (INVITED or CREATED), and JoinedTimestamp. The older Status field is deprecated in favor of State. This command must be run from the management account or a delegated administrator, and Organizations is a global service hosted in us-east-1. Pair it with aws organizations list-organizational-units-for-parent to map accounts onto your OU structure, and treat any account with JoinedMethod of INVITED as worth reviewing, since invited accounts often predate your baseline automation.

Frequently Asked Questions

Is one account per environment enough, or do I need one per workload too?

For a small estate, environment separation (dev, staging, prod) is a reasonable starting point. As soon as two workloads in the same environment have different data sensitivity, different compliance scope, or different teams deploying them, split them. The cost of an extra account is close to zero; the cost of a shared account during an incident is high.

Does a multi-account setup cost more?

Accounts themselves are free and billing is consolidated, so you keep volume discounts across the organization. The real costs are operational: more VPCs, more NAT gateways or shared networking, more endpoints, and the engineering time to automate account provisioning. Centralizing egress and using shared networking in a network account keeps those costs from scaling linearly with account count.

How do I give people access without creating IAM users in every account?

Use IAM Identity Center. Users authenticate once against your identity provider and assume roles in member accounts through permission sets, so there are no long-term credentials scattered across accounts and access reviews happen in one place.