IT Knowledge DB

AWS Organizations and SCPs

8 min read

AWS Organizations and SCPs

Organizations is AWS’s multi-account management service. An Organization groups many AWS accounts under one umbrella, gives you consolidated billing, and — crucially — lets you apply Service Control Policies (SCPs) that act as guardrails above IAM. In any serious AWS footprint, everything hangs off an Organization. Single-account design is a starter mistake.

Why multi-account is the default

Originally people ran one big AWS account. Now the idiom is one account per environment × workload × team — often dozens to thousands of accounts per org. Reasons:

  • Blast radius — IAM mistakes, forgotten resources, compromised keys stay contained
  • Quotas are per-account — one noisy workload can exhaust service quotas; separate accounts avoid it
  • Billing clarity — spend attribution per account is trivial; within an account is hard
  • Compliance / sovereignty — PCI workloads in their own account; production isolated from dev
  • Hard boundaries — some resources (SCPs, KMS key policies, SGs) can’t cross account lines, so accounts are the unit of isolation

Organizations makes this manageable — without it, N accounts = N payers, N sets of credentials, N islands. With Organizations, one payer, central governance, one identity story.

The Organization structure

  Root (the Organization itself)
   │
   ├── OU: Security
   │    ├── Account: log-archive
   │    └── Account: security-tooling
   │
   ├── OU: Workloads
   │    ├── OU: Prod
   │    │    ├── Account: payments-prod
   │    │    └── Account: website-prod
   │    └── OU: NonProd
   │         ├── Account: payments-dev
   │         └── Account: website-dev
   │
   └── OU: Sandbox
        └── Account: alice-sandbox
  • Root — the top of the tree (one per Org)
  • OU (Organizational Unit) — logical folder for accounts, nestable up to 5 deep
  • Account — an actual AWS account, placed in at most one OU

Policies attach at any level (Root / OU / Account) and inherit downward.

The management account

The Organization has a management account (formerly “master”) — the payer and creator. Everything else is a member account.

Rules of thumb for the management account:

  • Don’t run workloads there. Reserve it for Org-level tasks only.
  • Tight IAM. Root user locked with MFA, a hardware key in a safe, very few IAM users/roles, heavy CloudTrail monitoring.
  • Billing lives here. Consolidated billing, Savings Plans, Reserved Instance sharing across the Org.
  • Org changes originate here. Account creation, SCP attachment, AWS Config aggregator, Security Hub delegated administrator.

Delegated administrators: many services (Security Hub, Config, GuardDuty, IAM Access Analyzer, CloudTrail) can be “delegated” to a dedicated security/audit account so you don’t need to log into the management account for day-to-day ops.

Service Control Policies — guardrails above IAM

An SCP is a policy attached to the Root / an OU / an account that sets a ceiling on what IAM in that account can permit. SCPs don’t grant permissions — they only constrain.

Effective permissions = IAM ∩ SCP

   SCP says: "No one can call ec2:*"
   IAM says: "Alice may call ec2:RunInstances"
   → Alice cannot call ec2:RunInstances. SCP wins.

An SCP denial always beats an IAM allow. Nothing in the account can bypass the SCP — including the account root user.

Two styles of SCP

Allow-list SCP — only listed actions are permitted:

{
  "Effect": "Allow",
  "Action": ["ec2:*", "s3:*", "iam:*", "cloudwatch:*"],
  "Resource": "*"
}

Deny-list SCP — everything except listed actions is allowed:

{
  "Effect": "Deny",
  "Action": ["iam:DeleteUser", "cloudtrail:StopLogging"],
  "Resource": "*"
}

Deny-list is the common pattern in practice — more robust to new AWS services launching (you don’t have to add each to an allow-list).

Classic “guardrail” SCPs

  • Deny disabling / deleting CloudTrail — tamper-prevention
  • Deny region lockdown — “No action outside approved regions”
  • Deny root user usage (via aws:PrincipalType / aws:userid)
  • Deny removing MFA from IAM users
  • Deny making S3 buckets public
  • Deny disabling security services (GuardDuty, Config, Security Hub)
  • Deny creating specific expensive instance families in sandbox OUs
  • Require encrypted S3/EBS (deny unencrypted CreateVolume, PutObject)

These run at the OU level so they apply transparently to dozens/thousands of accounts.

SCP limits

  • SCPs cap IAM principals (users, roles, root)
  • SCPs don’t apply to the management account — this is by design and one reason you don’t run workloads there
  • SCPs don’t restrict service-linked roles (e.g. Auto Scaling’s own role)
  • 5 SCPs per entity (can attach multiple, combine their effects)

Other Organization policy types

SCPs are the most-used, but there are four others:

Policy typePurpose
SCPRestrict what IAM can do
Tag PolicyEnforce tag key/value conventions
Backup PolicyCentrally manage AWS Backup plans
AI Services Opt-out PolicyOpt out of AI services using your data for training
Declarative Policies (newer)Enforce resource configuration state

All inherit via the same OU tree mechanism.

Account creation and automation

Organizations supports programmatic account creation (CreateAccount API / Control Tower). Typical flow:

  1. New workload needs an account
  2. Pipeline (Control Tower Account Factory, AFT, or custom IaC) creates account in the right OU
  3. Baseline stacks deploy automatically: CloudTrail, Config, SSO permission sets, VPC baseline, IAM roles
  4. Owner gets access via IAM Identity Center (formerly SSO) with the right permission set

AWS Control Tower is the prescriptive package on top of Organizations — landing zone, guardrails (managed SCPs + Config rules), Account Factory. Most new Orgs start there.

Consolidated billing

One bill for the whole Org, sent to the management account’s payment method. Member accounts don’t see an invoice.

Sharing benefits across accounts:

  • Savings Plans & Reserved Instances apply Org-wide — an SP in the management account covers usage across all members, optimising automatically
  • Volume discounts tier across combined Org usage
  • Free-tier is technically per-account, but most discounts aggregate

Cost allocation tags let you attribute shared costs back to business units. CostCenter, Environment, Service are the common trio.

Resource sharing — RAM

AWS Resource Access Manager (RAM) is the companion for sharing specific resources across accounts within the Org: Transit Gateways, subnets, License Manager, Route 53 Resolver rules, many more.

Pattern: network account owns TGW + shared VPC; workload accounts attach/consume via RAM, never own the infrastructure.

Without Organizations, RAM still works but requires one-off invitation/accept per resource. With Organizations, you share to the whole Org or an OU transparently.

Security / audit integrations

Organizations is the backbone for security tooling:

  • GuardDuty — enable Org-wide; delegated administrator account sees findings from every account
  • Security Hub — aggregated findings across the Org
  • AWS Config — aggregator in one account showing compliance state of all accounts
  • IAM Access Analyzer — Org-level analyser finds unintended external sharing
  • CloudTrail Organization Trail — single trail covers all member accounts, non-tamperable by them
  • Macie / Inspector — similar delegated-administrator pattern

These services explicitly “know about” Organizations and reduce the per-account setup burden dramatically.

IAM Identity Center (formerly SSO)

For human access, IAM Identity Center is the Org-wide identity broker:

  • External IdP (Okta, Entra ID, Google Workspace) feeds users/groups
  • Permission sets defined once; assigned to users/groups per account
  • Users log in via one portal, click into any account/role they’re entitled to
  • Temporary STS credentials, no long-lived keys

Replaces the old pattern of N IAM users in N accounts. A must for multi-account at scale.

Common pitfalls

  1. Running workloads in the management account — SCPs don’t apply there, and its blast radius is existential. Keep it small.
  2. Overly permissive SCPs — allow-list SCPs that include "Action": "*" are pointless. Deny-list with specific forbidden actions is usually clearer.
  3. SCPs breaking production after attach. SCPs can deny actions the apps rely on (even ones nobody thought of). Test in Audit mode (simulate) or on a non-prod OU first.
  4. Service-linked roles surprises. Some services create their own roles; some SCPs inadvertently block them. Check error messages carefully; AWS docs list SLR exemptions.
  5. Region lockdown SCP that forgets global services are registered in us-east-1 — IAM / STS / Route 53 / CloudFront calls fail. Exempt us-east-1 or the specific global service ARNs.
  6. Too many OUs, too deep. 5-level nesting is possible; past 2-3 levels it becomes hard to reason about inheritance.
  7. Not using Control Tower when starting fresh — you’ll reinvent its baseline.
  8. Forgetting to enable all features. Organizations has “consolidated billing only” and “all features” modes; SCPs/tag policies/etc. require “all features.” Enable it early.

Mental model

  • Organizations = the container for your whole AWS estate. One payer, one umbrella, one identity story.
  • OUs = the sorting tree. Policies inherit down; you shape blast-radius + governance via the tree.
  • SCPs = the ceiling on IAM. Allowed = IAM ∩ SCP. Nothing — even root — escapes.
  • Management account = the crown jewel. Guard it; run nothing else there.
  • Delegated administrator + log-archive + security-tooling accounts = the canonical “foundational accounts” split.
  • Control Tower = the opinionated starting template for all of the above.

See also

Graph View

Backlinks