Every AWS deployment starts in a single account. A startup’s first EC2 instance, a developer’s side project, a proof of concept that became production—single account, simple billing, everything in one place.
Then things get complicated. Developers need sandbox environments. Compliance requires production isolation. Different teams step on each other. Security boundaries become important. The single account that worked fine at ten people becomes a liability at fifty.
This is where multi-account architecture comes in, and getting it right early saves enormous pain later.
Why Multiple Accounts?
AWS accounts provide hard boundaries that nothing else in AWS can replicate:
Security isolation. Resources in different accounts can’t see each other by default. A compromised IAM user in the dev account can’t list production EC2 instances. This blast radius reduction is the primary reason for multi-account structures.
Billing separation. Each account gets its own bill. Chargebacks to business units, cost allocation to projects, or simply understanding where money goes becomes straightforward when accounts map to cost centers.
Service limits isolation. AWS service limits (quotas) are per-account. The team running a thousand Lambda functions won’t exhaust limits that affect production.
Simplified permissions. Instead of complex IAM policies with resource conditions, you can give developers full access to their own account. Simpler policies mean fewer mistakes.
Compliance boundaries. When auditors ask about production access controls, showing that production is in a separate account with restricted access is cleaner than explaining IAM policy conditions.
The Single-Account Ceiling
You can push a single account pretty far. With careful IAM, resource tagging, and organizational discipline, a team of 20–30 can function in one account. But signs you’ve hit the ceiling include:
- IAM policies becoming unmanageable (hundreds of lines with resource conditions)
- Developers accidentally modifying production resources
- Difficulty tracking costs to projects or teams
- Audit findings about inadequate separation
- Fear of making changes because “everything is connected”
- Service quotas becoming a recurring issue
When these symptoms appear, it’s time for multi-account—ideally before you’re in an emergency.
Account Structure Patterns
The Workload-Based Structure
The most common pattern: separate accounts by workload and environment.
Organization Root
├── Core/Infrastructure
│ ├── Networking (Transit Gateway, shared VPCs)
│ ├── Security (GuardDuty, Security Hub, Config)
│ ├── Logging (CloudTrail, centralized logs)
│ └── Identity (SSO, identity management)
├── Workload A
│ ├── Development
│ ├── Staging
│ └── Production
├── Workload B
│ ├── Development
│ ├── Staging
│ └── Production
└── Sandbox (developer playgrounds)
Each workload (application, product, or service domain) gets its own set of environment accounts. Core infrastructure accounts provide shared services.
Pros: Clear mapping between accounts and what they contain. Easy to understand cost allocation. Natural security boundaries.
Cons: Account proliferation at scale. Shared services require cross-account access patterns.
The Team-Based Structure
Organize accounts by team ownership:
Organization Root
├── Core/Infrastructure
├── Team Alpha
│ ├── Production
│ └── Non-Production
├── Team Beta
│ ├── Production
│ └── Non-Production
└── Sandbox
Pros: Teams have full autonomy over their accounts. Aligns with organizational structure.
Cons: Shared workloads become complicated. Team reorganizations require account restructuring.
The Hybrid Approach
Most organizations end up with a hybrid. Core infrastructure in shared accounts, major products in dedicated account sets, smaller workloads grouped logically.
The key is having a rationale for account boundaries that makes sense for your organization. There’s no universal “right” structure.
AWS Organizations: The Foundation
AWS Organizations is the control plane for multi-account management:
- Centralized billing: One payer account, consolidated invoices, volume discounts across all accounts.
- Service Control Policies (SCPs): Guardrails that restrict what any account can do, regardless of IAM permissions.
- Account provisioning: Create new accounts programmatically.
- Organizational Units (OUs): Group accounts for policy application.
Set up Organizations early, even if you only have one or two accounts. Migration later is possible but more painful than starting organized.
Organizational Units
OUs group accounts for SCP application. Common OU structures:
Root
├── Security OU
├── Infrastructure OU
├── Workloads OU
│ ├── Production OU
│ └── Non-Production OU
└── Sandbox OU
Apply SCPs at the OU level. All accounts in Production OU get the same guardrails. Add a new production account, and it inherits the policies automatically.
Service Control Policies
SCPs are permission boundaries—they restrict what IAM allows, but don’t grant permissions themselves. Common SCP patterns:
- Prevent disabling CloudTrail or GuardDuty
- Restrict certain regions (only allow us-east-1, us-west-2)
- Prevent leaving the organization
- Require IMDSv2 for EC2 instances
- Block certain expensive or risky services
SCPs apply even to account root users. They’re your last line of defense against misconfigured IAM.
Account Provisioning and Automation
With multiple accounts, manual account setup becomes impractical. You need automation:
AWS Control Tower provides a pre-built landing zone with account vending, baseline security controls, and guardrails. It’s opinionated but handles the common case well.
Account Factory for Terraform (AFT) provides GitOps-style account provisioning with Terraform. More flexible than Control Tower but requires more setup.
Custom solutions using AWS Organizations APIs work for organizations with specific requirements, but you’re building and maintaining the automation yourself.
However you provision, new accounts should come with:
- Configured CloudTrail logging
- Baseline security services enabled (GuardDuty, Security Hub)
- Networking connectivity to shared infrastructure
- IAM Identity Center access configured
- Tagging baseline
An account that requires hours of manual setup encourages people to avoid creating accounts when they should.
Identity and Access Management
IAM Identity Center (formerly AWS SSO) is the standard for multi-account identity. Users authenticate once and access any account they’re authorized for through a portal. No per-account IAM users, no managing credentials across dozens of accounts.
Permission sets define what users can do. Map permission sets to groups and accounts:
- Platform team gets AdministratorAccess to all accounts
- Developers get PowerUserAccess to dev/sandbox, ReadOnlyAccess to production
- On-call engineers get emergency access to production via just-in-time elevation
Service roles across accounts require more thought. When a service in Account A needs to access resources in Account B, you use cross-account IAM roles with trust policies. Define these patterns once and apply them consistently.
Networking Patterns
Multi-account networking is where complexity accumulates. Options range from simple to elaborate:
VPC peering works for a handful of VPCs that need connectivity. It’s simple but doesn’t scale—peering is one-to-one, and transitive routing doesn’t work.
Transit Gateway is the hub-and-spoke model for larger deployments. VPCs in each account attach to a central Transit Gateway. Routing becomes manageable even with many accounts.
Centralized egress routes internet-bound traffic through a shared NAT Gateway or firewall. Cost efficiency and security inspection in one pattern.
Private endpoints via AWS PrivateLink keep traffic to AWS services on the AWS network. Especially important for security-sensitive services like Secrets Manager.
The right approach depends on your connectivity requirements. Not every account needs to talk to every other account. Define the patterns, document them, and enforce them through network team review.
Common Mistakes
Too few accounts too long. Organizations often wait until the single-account pain is acute before splitting. By then, untangling the monolith is a project in itself. Split proactively.
Too many accounts without automation. Account sprawl without consistent provisioning leads to drift. Every account is configured slightly differently. Inconsistency creates operational burden and security gaps.
Inconsistent tagging. Cost allocation and resource identification depend on consistent tagging. Define a tagging strategy early and enforce it.
Ignoring networking until it’s painful. Account-level isolation is great until services need to communicate. Plan networking patterns upfront rather than bolting them on.
No account vending process. If creating a new account requires a week of manual work and three approvals, people will cram everything into existing accounts. Make account creation easy and controlled.
Getting Started
If you’re outgrowing a single account:
Set up AWS Organizations and a management account. This account holds no workloads—just organization management.
Enable CloudTrail organization trail. Centralized audit logging across all accounts from day one.
Set up IAM Identity Center. Start using SSO before IAM user sprawl gets worse.
Create initial account structure. At minimum: management account, security/logging account, workload account(s), sandbox account.
Define baseline SCPs. Start with guardrails: prevent CloudTrail disable, restrict regions, require security baseline.
Automate account provisioning. Whether Control Tower, AFT, or custom—new accounts should be consistent and quick.
Migrate workloads incrementally. Don’t try to reorganize everything at once. Move workloads to appropriate accounts over time, starting with net-new projects.
The Long Game
Multi-account architecture is a long-term investment. The structure you build now will shape how you operate for years. Design it thoughtfully:
- Plan for growth (new teams, new products, acquisitions)
- Optimize for your organization’s needs, not AWS’s prescribed patterns
- Invest in automation early—manual processes don’t scale
- Review and refine as you learn what works and what doesn’t
Done well, multi-account AWS is more secure, easier to manage at scale, and clearer to reason about than a sprawling single account. The investment pays off as the organization grows.