Multi-account strategy and governance

Mature AWS customers don't put everything in one account. Separate accounts give the strongest boundary for security, billing and blast radius. The exam expects you to know how to govern many accounts centrally.

Why multiple accounts

• Isolation — a mistake or breach in one account doesn't spread.
• Separate environments — production, staging, development.
• Billing clarity — costs per team or product.
• Different compliance needs — regulated workloads in dedicated accounts.
• Service quotas — limits are per account.

AWS Organizations

Organizations groups accounts under a management account:

• Organizational units (OUs) — folders of accounts (e.g. Security, Production, Sandbox), nested up to several levels.
• Consolidated billing — one bill; usage is aggregated for volume discounts, and Reserved Instance / Savings Plans discounts can be shared across accounts.
• Policies — service control policies, tag policies, backup policies and others applied to OUs or accounts.
• Organization-wide features — trails (CloudTrail), delegated administrators for security services, and resource sharing.

Service control policies (SCPs)

SCPs set the maximum permissions for accounts in an OU. They don't grant anything.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingAllowedRegions",
      "Effect": "Deny",
      "NotAction": ["iam:*", "organizations:*", "sts:*", "support:*", "cloudfront:*", "route53:*"],
      "Resource": "*",
      "Condition": { "StringNotEquals": { "aws:RequestedRegion": ["ap-south-1", "eu-west-1"] } }
    },
    {
      "Sid": "ProtectCloudTrail",
      "Effect": "Deny",
      "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail"],
      "Resource": "*"
    }
  ]
}

Key facts:

• SCPs affect all users and roles in member accounts, including the root user of those accounts.
• SCPs do not affect the management account — keep workloads out of it.
• An explicit Deny in an SCP can't be overridden by anything in the account.

AWS Control Tower

Control Tower sets up and governs a multi-account environment following AWS best practices — a landing zone:

• Creates core accounts (log archive, audit) and an organization structure.
• Controls (guardrails):
  • Preventive — implemented with SCPs (stop actions).
  • Detective — implemented with AWS Config rules (find non-compliance).
  • Proactive — check resources before they're provisioned (CloudFormation hooks).
• Account Factory — vend new, pre-configured accounts on demand.
• A dashboard of compliance across accounts.

Exam cue: "set up a secure multi-account environment quickly with best-practice guardrails" → Control Tower.

Sharing and standardising

A typical account structure

Management account (billing, Organizations only)
├── Security OU
│   ├── Log Archive account   (central CloudTrail / Config logs)
│   └── Audit / Security account (GuardDuty, Security Hub delegated admin)
├── Infrastructure OU
│   └── Network account (Transit Gateway, Direct Connect, shared VPCs via RAM)
├── Workloads OU
│   ├── Production accounts
│   └── Non-production accounts
└── Sandbox OU (experiments, strict budgets)

Exam patterns

• "Central billing with volume discounts across accounts" → Organizations with consolidated billing.
• "Developers must only use approved instance types / Regions" → SCP with conditions.
• "Share a Transit Gateway with other accounts" → RAM.
• "Give teams self-service, compliant infrastructure" → Service Catalog.
• "Ensure all accounts send logs to a central account" → organization trail in CloudTrail, landing zone with a log archive account.

Written by Bipin Singh

Senior Full-Stack Engineer · AI & AWS. I design and run production systems on AWS — serverless, data and AI.

Work with me