Why Multiple Accounts?
A single AWS account works fine for small projects, but it becomes a liability as you grow. Everything shares the same IAM namespace, the same service quotas, and the same blast radius. A misconfigured IAM policy in development can affect production. A runaway process can exhaust quotas for the entire organization.
Multiple accounts provide hard boundaries. Each account has its own IAM, its own quotas, and its own billing. A security incident in one account doesn't automatically compromise others. Cost allocation becomes trivial—just look at the account's bill.
Common Account Structures
Environment-Based (Most Common)
Separate accounts for development, staging, and production. Simple to understand, clear cost attribution, and prevents dev mistakes from affecting prod.
Example: dev-account, staging-account, prod-account
Workload-Based
Separate accounts per application or service. Useful when different teams own different workloads, or when workloads have different compliance requirements.
Example: payments-prod, inventory-prod, analytics-prod
Tenant-Based (Multi-Tenant SaaS)
Separate accounts per customer for maximum isolation. Required by some enterprise customers and compliance frameworks. Higher operational overhead but strongest security boundaries.
Example: customer-acme-prod, customer-globex-prod
Essential Accounts
Beyond workload accounts, most organizations need several foundational accounts:
Management Account
The root of your AWS Organization. Contains Organizations configuration, SCPs, and consolidated billing. Keep workloads out of this account—it's too privileged.
Security/Audit Account
Centralized CloudTrail logs, GuardDuty findings, Security Hub aggregation. Read-only access to other accounts for security team. Locked down—only security personnel have access.
Log Archive Account
Long-term storage for CloudTrail, VPC Flow Logs, and application logs. S3 bucket policies prevent deletion. Separate from security account for defense in depth.
Shared Services Account
Central resources used by multiple accounts: Transit Gateway, shared VPCs, CI/CD pipelines, container registries. Reduces duplication and simplifies networking.
Service Control Policies (SCPs)
SCPs are guardrails that limit what actions can be taken in member accounts, regardless of IAM permissions. They're your safety net against misconfigurations and compromised credentials.
Common SCP patterns:
- Deny region access — Restrict workloads to approved regions (us-east-1, us-west-2) to simplify compliance and reduce attack surface.
- Require encryption — Deny creation of unencrypted S3 buckets, EBS volumes, and RDS instances.
- Protect security services — Prevent disabling CloudTrail, GuardDuty, or Config in member accounts.
- Restrict root user — Deny all actions by root user except specific break-glass scenarios.
- Limit expensive services — Prevent accidental use of costly services in dev accounts.
Cross-Account Access Patterns
With multiple accounts, you need secure ways to access resources across boundaries:
IAM Role Assumption
Create roles in target accounts that can be assumed by principals in source accounts. Use external IDs for third-party access. This is the standard pattern for most cross-account scenarios.
Resource-Based Policies
S3 buckets, KMS keys, and some other resources support policies that grant access to other accounts directly. Simpler than role assumption for specific resources.
AWS RAM (Resource Access Manager)
Share resources like Transit Gateway attachments, subnets, and License Manager configurations across accounts without copying them.
Control Tower vs. DIY
AWS Control Tower provides a pre-built landing zone with account factory, guardrails, and dashboards. It's a good starting point for organizations new to multi-account, but it's opinionated and can be limiting.
For organizations with specific requirements or existing infrastructure, building your own landing zone with CDK or Terraform gives more flexibility. The trade-off is more upfront work and ongoing maintenance. I typically recommend Control Tower for greenfield projects and custom solutions when you're migrating existing infrastructure or have unusual requirements.
Common Pitfalls
- Too many accounts too fast — Start with the essentials (management, security, log archive, one per environment). Add more as you identify clear needs.
- Inconsistent tagging — Without consistent tags across accounts, cost allocation and resource management become painful. Enforce tagging policies early.
- Manual account provisioning — Use Account Factory (Control Tower) or CDK/Terraform to provision accounts consistently. Manual setup leads to drift.
- Overly permissive cross-account roles — Cross-account roles should follow least privilege. Don't create admin roles just because it's easier.
- Forgetting networking — Multiple accounts need a networking strategy. Transit Gateway, VPC peering, or PrivateLink—plan this before you have 20 accounts that can't talk to each other.