AWS
Intermediate 15 min read AWS

AWS Organizations and Accounts

The skeleton of a well-governed AWS estate

AWS Organizations turns one bill into many isolated accounts with service control policies at folders. It's the standard skeleton of every serious AWS estate.

AWS Organizationsservice control policySCPaccountOUlanding zone
Prerequisites: Cloud Account Structure AWS Service Map
Before we start

What you will learn

  • Structure accounts into OUs under AWS Organizations
  • Write service control policies that constrain without breaking
  • Use consolidated billing and guardrails at the right level
In 60 seconds

AWS Organizations groups accounts under a management account, applies service control policies (SCPs) at OU/folder level to forbid actions, and consolidates billing. It's how you get many isolated clouds with one governance story.

Introduction

What is this?

AWS Organizations is the governance container for multiple AWS accounts. A management (payer) account sits atop organizational units (OUs) — folders like 'prod', 'dev', 'security' — each containing accounts. Service control policies (SCPs) attach to OUs/accounts and set maximum permissions (they can only limit, never grant). Consolidated billing rolls all usage into one invoice, and guardrails inherit down the tree. AWS Control Tower turns this skeleton + guardrails + logging into a repeatable landing zone.

Motivation

Why do you need it?

  • Separate accounts contain blast radius: a compromised dev account can't reach production.
  • SCPs make 'no production regions, no public storage, root only for break-glass' enforceable, not advisory.
  • Billing per account turns attribution into structure.
  • Landing-zone patterns standardize security, logging and identity from day one.
Think about it

Mental model

Imagine

A corporate HQ with department wings and a security policy handbook

Think of

AWS Organizations

HQ (management account) writes the rulebook (SCPs); wings (OUs) inherit it; each office (account) runs its own personnel and budget but can't break building-wide rules.

Mechanics

How it works

  • The management account creates OUs and member accounts; each member is isolated but shares the consolidated bill.
  • SCPs attach at root/OU/account and bound which IAM actions may ever succeed within child accounts.
  • IAM policies grant within an account; SCPs limit the ceiling — the effective permission is the intersection.
  • Control Tower / landing zones provision the skeleton, guardrails and central logging in a repeatable way.
  • Features must be enabled (all features) for SCPs, centralized root access and cross-account roles.

A canonical AWS organization.

Management account
Security OU
Dev OU
Prod OU
Consolidated billing
Real world

In production

  • An enterprise org runs prod and dev under separate OUs; an SCP at the prod OU denies member accounts from leaving the approved regions.
  • A startup consolidates billing so finance sees per-team costs the moment an account exists.
  • A security team uses Control Tower to pre-enforce 'no publicly reachable buckets' against every future account.
Guidelines

Best practices

  • Keep the management account for governance only — MFA + break-glass roles, no daily workloads.
  • Prefer deny-type SCPs for guardrails; roll them out in a monitoring/reporting mode first.
  • Attach guardrails high (OU level) and grants low (account level) so containment inherits.
  • Enable CloudTrail at org level and send logs to a central security account.
Watch out

Common mistakes

  • Running production workloads in the management account.
  • Writing deny SCPs first and breaking existing pipelines — always stage through audit mode.
  • Letting accounts proliferate without names or owners, spawning ungovernable ghost accounts.
  • Putting all identity in the management account instead of federated SSO + scoped roles.
Root cause analysis

Common issues

Error
Dev account can't create resources a new pipeline needs
Root cause

A deny SCP added earlier now blocks the new service globally

Fix

Review SCP effect logs, scope the deny to specific resources/conditions, or exclude the dev OU.

Error
Root user of a member account is inaccessible
Root cause

Centralized root access disabled root credentials and no IAM role was provisioned

Fix

Working-as-intended in hardened landings — establish the cross-account role and break-glass process first.

When things break

Debugging tips

  • 'Not authorized' with a permissive IAM policy usually means an SCP is denying higher up — check the OU chain.
  • Use CloudTrail (lookup with AccessKeyId/SourceIP) to prove which policy or SCP denied a call.
  • When a guardrail breaks a migration, move the resource to the correct OU rather than editing the SCP to fit the oddball.
  • Document OU names and purposes — a folder called 'prod2-backup' is a governance warning sign.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

Which artifact sets the maximum permission ceiling for everything in an OU?

2

SCPs can grant additional permissions to a user.

Go deeper

Official documentation

AWS — Organizations user guide
docs
AWS — Service control policies
docs
AWS — Control Tower
docs