A single AWS account mixes everything: dev, staging, production, security tools, and logs. This creates risk: a misconfigured resource in dev could impact production, costs are hard to track, and access controls become complex.

AWS recommends a multi-account strategy where you separate workloads, environments, and functions into dedicated accounts. Each account provides isolation: separate IAM boundaries, billing, service limits, and resource quotas.

While you can have many accounts, AWS best practices start with a foundational 5-account structure:

1. Management/Security Account: Contains AWS Organizations, IAM Identity Center (SSO), AWS Config aggregator, Security Hub, GuardDuty, and Service Control Policies (SCPs). This is your governance hub—the single place where you define guardrails that apply to all accounts.

2. Log Archive Account: A write-only destination for centralized logging. All CloudTrail logs, VPC Flow Logs, ALB access logs, and Config snapshots flow here. This account is locked down so logs cannot be deleted or modified, meeting compliance requirements.

3. Shared Services Account: Hosts common infrastructure used by multiple workload accounts: Transit Gateway for networking, Route 53 for DNS, CI/CD runners (CodeBuild, Jenkins agents), bastion hosts, and shared container registries (ECR).

4. Non-Prod Workloads Account: Contains development, testing, and staging environments. Developers have broader access here to experiment and iterate. Cost controls are less strict, but SCPs still enforce security guardrails.

5. Production Workloads Account: Highly restricted production environment. Only CI/CD pipelines and a small SRE team can make changes. Human access is read-only with break-glass roles requiring MFA and approval workflows.

SCPs are guardrails that apply at the organization or OU level. They define what actions are denied across accounts, regardless of IAM permissions. Think of them as safety nets: even if someone has admin permissions in an account, an SCP can block dangerous operations.

Common SCP examples: prevent public S3 buckets, restrict regions to approved ones only, require encryption for EBS volumes and RDS, block root account usage, and prevent deletion of CloudTrail logs.

SCPs use deny-by-default logic: if an SCP denies an action, it cannot be allowed by IAM. This ensures consistent security posture across all accounts.

All accounts send CloudTrail logs to the Log Archive account via an organization trail. This gives you a single source of truth for audit and compliance. VPC Flow Logs, ALB access logs, and application logs also flow to centralized S3 buckets or CloudWatch Logs.

AWS Config runs in each account but aggregates findings to the Management account. Security Hub collects security findings from GuardDuty, Config, and other services, giving you a unified security dashboard.

This centralized approach means you can answer questions like "Who accessed this resource?" or "What changed in production?" without logging into multiple accounts.

IAM Identity Center (formerly AWS SSO) in the Management account provides single sign-on for all accounts. Users authenticate once and can access multiple accounts based on permission sets.

Permission sets define roles (e.g., `Prod-ReadOnly`, `NonProd-Developer`, `Security-Audit`) that are assigned to users or groups. When a user accesses an account, they assume a role with those permissions.

This eliminates the need to manage IAM users in each account and provides centralized access control with audit trails.

Workload accounts need to connect to shared services and sometimes to each other. AWS provides several options:

VPC Peering: Direct connections between VPCs in different accounts. Simple but does not scale well with many accounts.

Transit Gateway: A central hub in the Shared Services account that all accounts connect to. More scalable and easier to manage than many peering connections.

PrivateLink: For service-to-service communication without exposing VPCs. Ideal for accessing shared APIs or databases.

VPC Endpoints: Allow private access to AWS services (S3, SSM, Secrets Manager) without traversing the internet, even across accounts.

Within Non-Prod and Production accounts, you deploy the same 3-tier architecture per environment:

Web Tier: Route 53 → AWS WAF → Application Load Balancer (ALB) in public subnets across multiple availability zones. ALB terminates TLS and routes traffic to the app tier.

App Tier: ECS on Fargate, EKS, or EC2 Auto Scaling Groups in private subnets. Containers or instances pull images from ECR in the Shared Services account. Apps fetch secrets from Secrets Manager or Parameter Store.

Data Tier: RDS (PostgreSQL, MySQL) in private data subnets with Multi-AZ for high availability. ElastiCache for caching. All data encrypted at rest with KMS keys managed in the Management account.

Security groups enforce least-privilege networking: web tier can only reach app tier on HTTP/HTTPS, app tier can only reach data tier on database ports, and data tier has no internet access.

CI/CD pipelines run in the Shared Services account or in each workload account. They use cross-account IAM roles to deploy:

1. Pipeline assumes a role in the target account (Non-Prod or Prod)

2. Role has permissions to update ECS/EKS, RDS, and other resources

3. Deployment happens without storing credentials in the pipeline

For production, pipelines require manual approval gates and can only deploy artifacts that passed tests in Non-Prod. This enforces promotion workflows and prevents untested code from reaching production.

Each account has its own billing, making it easy to track costs by environment, team, or project. AWS Cost Explorer and budgets can be set per account or aggregated across the organization.

Tags applied consistently across accounts (e.g., `Environment: prod`, `Project: webapp`) enable cost allocation reports that show spending by project or team, regardless of which account resources live in.