AWS Organizations and Multi-Account Strategy

AWS Organizations — Managing Multiple Accounts

As companies grow, they create multiple AWS accounts: one for production, one for development, one for security tooling, one for each business unit. AWS Organizations manages all these accounts centrally.

Why Multiple AWS Accounts?

• Blast radius limitation: if dev account is compromised, production account is unaffected
• Cost allocation: separate bills per team, project, or environment
• Security isolation: different security policies per environment
• Service quota isolation: dev workloads cannot exhaust production quotas
• Compliance: regulated workloads (PCI, HIPAA) in dedicated compliant accounts

AWS Organizations Structure

Root
  Management Account (billing, org control - touch nothing else here)
  |
  OU: Security
  |   Account: Security-Tooling (GuardDuty, Security Hub, CloudTrail)
  |   Account: Log-Archive (centralised logs)
  |
  OU: Infrastructure
  |   Account: Networking (shared VPC, Transit Gateway, DNS)
  |   Account: Shared-Services (ECR, CodeArtifact)
  |
  OU: Workloads
      OU: Production
      |   Account: App1-Prod
      |   Account: App2-Prod
      OU: Development
          Account: App1-Dev
          Account: App2-Dev

Service Control Policies (SCPs)

SCPs are permission guardrails applied at the OU or account level. Even if an IAM policy grants a permission, an SCP can DENY it. SCPs cannot grant permissions — they only restrict.

# SCP example: Prevent disabling CloudTrail in any account
{
  "Effect": "Deny",
  "Action": "cloudtrail:StopLogging",
  "Resource": "*"
}

# SCP example: Restrict to approved regions only
{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["us-east-1", "eu-west-1"]
    }
  }
}