Multi-Account Strategy and AWS Organizations

1Why Many Accounts

An AWS account is the strongest isolation boundary AWS offers: separate IAM, quotas, billing, and blast radius. Putting everything in one account means one compromised credential, one runaway script or one quota exhaustion affects everything. The recommended practice is many accounts, organized by purpose:

2AWS Organizations

• Accounts grouped into organizational units (OUs): Security, Infrastructure, Workloads/Prod, Workloads/NonProd, Sandbox, Suspended.
• Consolidated billing (volume discounts, shared Savings Plans/RIs) — 24-cost_optimization_and_well_architected/.
• Policies:
  • SCPs (service control policies) — maximum permissions for accounts in an OU (even root): deny regions, deny disabling security services, deny leaving the org, require IMDSv2… (21-iam_deep_dive/)
  • RCPs (resource control policies) — maximum permissions on resources (e.g. no S3/KMS/Secrets access from outside the organization)
  • declarative policies (EC2 baseline settings), tag policies, backup policies, AI opt-out policies
• Delegated administrators for security services so the management account stays clean.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideApprovedRegions",
    "Effect": "Deny",
    "NotAction": ["iam:*", "organizations:*", "sts:*", "support:*", "cloudfront:*", "route53:*", "budgets:*"],
    "Resource": "*",
    "Condition": { "StringNotEquals": { "aws:RequestedRegion": ["eu-west-1", "eu-central-1"] } }
  }]
}

3Control Tower and Landing Zones

A landing zone is the pre-configured multi-account baseline. AWS Control Tower builds and governs one: creates the Security OU with log archive and audit accounts, sets up IAM Identity Center, an organization-wide CloudTrail, AWS Config, and applies controls (preventive = SCPs/RCPs, detective = Config rules, proactive = CloudFormation Hooks). Account Factory (or Account Factory for Terraform, AFT) vends new accounts with baselines (VPC, roles, budgets) in minutes.

4Identity Across Accounts

• IAM Identity Center with your IdP: users get permission sets (e.g. ReadOnly, Developer, Admin) per account; no IAM users anywhere.
• Workloads and CI use cross-account roles (OrganizationAccountAccessRole only for break-glass; purpose-built deploy roles otherwise).
• Use aws:PrincipalOrgID in resource policies to allow "anyone in our org" safely.

5Networking Across Accounts

• Transit Gateway (hub-and-spoke routing between VPCs and on-prem), VPC sharing via Resource Access Manager (central network team owns subnets, workload accounts launch into them), PrivateLink for exposing specific services.
• Centralized egress/inspection VPC (NAT + Network Firewall) and centralized DNS (Route 53 Resolver rules shared via RAM).
• Plan non-overlapping CIDRs across all accounts from day one (IPAM).

6Central Security and Logging

• Organization CloudTrail → log archive account bucket (object lock, restricted access).
• GuardDuty, Security Hub, Config, IAM Access Analyzer, Inspector enabled org-wide with a delegated admin in the security account.
• Budgets and cost anomaly detection per account; tags enforced by tag policies.

Under the HoodHow SCPs Combine With IAM▾

An SCP grants nothing by itself; it defines the maximum permissions available to principals in an account. When a principal in a member account makes a request, AWS evaluates the SCPs attached to every level from the organization root down through each parent OU to the account — the request must be allowed at every level (the default FullAWSAccess SCP allows everything, so in practice guardrails are written as explicit Deny statements). The SCP result is intersected with the account's own identity and resource policies (21-iam_deep_dive/ evaluation logic). SCPs don't apply to the management account or to service-linked roles, which is one reason the management account must not host workloads — and why sensitive operations there must be tightly controlled.

⚠️ Common Pitfalls

1. Workloads in the management account.
2. One account for prod and dev.
3. IAM users per account instead of Identity Center.
4. Overlapping VPC CIDRs that block peering/Transit Gateway later.
5. SCPs tested in production OUs first — test in a sandbox OU.
6. No log archive isolation — attackers delete trails in the same account.

📋 Quick Reference

accounts: management (no workloads) · security (log archive, audit) · infrastructure · workloads per app×env · sandbox
Organizations: OUs + SCPs/RCPs/tag/backup policies · consolidated billing · delegated admins
landing zone: Control Tower (+ Account Factory / AFT) · Identity Center permission sets
network: Transit Gateway, VPC sharing (RAM), PrivateLink, IPAM · org-wide CloudTrail, GuardDuty, Security Hub, Config

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: aws_multi_account_and_organizations_theory.md · generated by tools/build_lessons.py