AWS Organizations

What is AWS Organizations?

AWS Organizations lets you centrally manage multiple AWS accounts as a single organization. Instead of a sprawl of unrelated accounts with separate bills and no shared controls, you get a hierarchy: a management (root) account, accounts grouped into Organizational Units (OUs), consolidated billing across all of them, and — most importantly — Service Control Policies (SCPs) that set guardrails on what any account is even permitted to do. It’s the foundation of the modern multi-account strategy that AWS itself recommends for any non-trivial deployment.

Why multiple accounts — and why this matters

The instinct of newcomers is to run everything in one AWS account with different IAM users. AWS’s guidance is the opposite: use many accounts as isolation boundaries — separate accounts for production, staging, and development; separate accounts per team, project, or workload. The reason is that an AWS account is the strongest isolation boundary AWS offers. A misconfiguration, a compromised credential, or a runaway cost in one account is contained to that account — it can’t automatically bleed into production. Separate accounts also give clean per-workload cost attribution, independent security blast radius, and simpler compliance scoping. AWS Organizations is what makes running dozens or hundreds of accounts manageable rather than chaotic: consolidated billing means one invoice and volume discounts pooled across accounts, and centralized management means you configure guardrails and shared services once at the org level.

SCPs — the guardrails that trip people up

The most powerful and most misunderstood feature is Service Control Policies. An SCP sets the maximum permissions available to accounts (or OUs) — it defines the ceiling on what’s allowed, not what is allowed. This is the critical distinction: an SCP does not grant any permissions; it only limits them. Even a full-admin IAM user in a member account cannot do something an SCP denies — the SCP caps everyone, including account admins. That makes SCPs the right tool for organization-wide guardrails: “no account may disable CloudTrail,” “no account may launch resources outside approved regions,” “no account may leave the organization.” But the not-a-grant nature is exactly where people get confused and locked out: because effective permissions are the intersection of SCPs and IAM policies, a user needs the action allowed by both their IAM policy and the applicable SCPs. Teams routinely puzzle over “my IAM policy allows this, why is it denied?” — the answer is an SCP capping it above. It pairs with AWS Control Tower, which automates setting up a well-architected multi-account landing zone (OUs, guardrails, logging accounts) on top of Organizations, so most teams adopt Control Tower rather than wiring Organizations by hand.

What people get wrong

• Thinking SCPs grant permissions — they only set the ceiling; you still need IAM policies to grant, and effective access is the intersection of both.
• Running everything in one account: a single account is a weak isolation boundary — separate prod/dev/team accounts contain blast radius and cost.
• Locking out the org with a broad SCP — an overly aggressive Deny (even on the management account path) can cut off access; test SCPs carefully before applying at the root.

Primary source: AWS Organizations documentation