AWS Organizations & Service Control Policies
Managing many AWS accounts as one organization — centralized billing, and Service Control Policies that set permission guardrails no IAM policy within a member account can override.
Want a visual for this topic?
Generate a diagram tailored to AWS Organizations & Service Control Policies — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain why companies use multiple AWS accounts instead of one
- •Explain what a Service Control Policy does and how it differs from an IAM policy
- •Explain the role of Organizational Units in structuring an AWS Organization
- •Explain what AWS Control Tower adds on top of Organizations
What is it?
AWS Organizations lets you centrally manage multiple AWS accounts as a single organization — with consolidated billing, and Service Control Policies (SCPs) that set maximum permission boundaries applying across entire groups of accounts, which no IAM policy inside a member account can grant access beyond, regardless of how permissive that account's own IAM policies are.
Why it exists
As companies grow, using a single AWS account for everything becomes a real liability: a mistake or compromise in one team's resources can affect every other team sharing that account, billing becomes hard to attribute per team/project, and there's no strong boundary preventing one team's IAM administrator from accidentally (or maliciously) affecting another team's resources. AWS Organizations exists to let a company use multiple, genuinely isolated AWS accounts (one per team, environment, or project) while still centrally managing billing and enforcing company-wide security guardrails across all of them.
Problem it solves
It solves the blast-radius problem (a security incident or mistake in one account doesn't directly affect resources in a different account, since accounts are strong isolation boundaries), the centralized-guardrail problem (a company-wide security policy — e.g. 'no account may ever disable CloudTrail logging' — can be enforced via an SCP that no individual account's administrator can override, even if they have full admin IAM permissions within their own account), and the billing-visibility problem (consolidated billing gives one combined bill with per-account cost breakdown, plus volume discounts that apply across the whole organization's combined usage).
Intuition
Think of a large company with many departments, each with their own separate office space (AWS account) with their own department head having full authority over their own office's day-to-day decisions — but the company's central facilities/legal team (Organizations + SCPs) sets certain non-negotiable building-wide rules (fire exits must stay clear, no explosives allowed) that apply to every department's office regardless of what that department head might otherwise decide, no matter how much authority they have within their own space.
Analogy
A franchise business: each individual franchise location (AWS account) is run day-to-day by its own local manager with real decision-making authority over local operations, but the franchise corporate office (AWS Organizations root/management account) sets certain absolute, non-negotiable brand-wide rules (health code minimums, required insurance) that apply to every location regardless of what that location's manager might otherwise want to do.
Technical explanation
An SCP is a JSON policy, syntactically similar to an IAM policy, but functioning fundamentally differently: it doesn't grant any permissions on its own — it defines the maximum available permissions for accounts it's attached to, acting as a filter on top of whatever IAM policies exist within that account. Even a member account's root user or an IAM policy granting AdministratorAccess cannot exceed what the applicable SCPs allow — an explicit SCP Deny always wins, exactly like the explicit-deny-always-wins rule within a single account's IAM evaluation, just operating one level higher, across the whole organizational hierarchy. AWS Control Tower is a higher-level service built on top of Organizations, automating the setup of a well-architected multi-account environment (a 'landing zone') with pre-configured OUs, SCPs implementing common security guardrails, centralized logging, and self-service account provisioning — essentially packaging AWS's own best-practice multi-account setup as a guided, automated service rather than something you'd otherwise assemble manually from Organizations primitives.
Architecture
A company structures its AWS Organization with a 'Production' OU (containing each team's production account, with a restrictive SCP preventing any account from disabling CloudTrail or leaving specific Regions), a 'Development' OU (looser SCPs, but still blocking certain genuinely dangerous actions like deleting the organization's central logging bucket), and a 'Sandbox' OU for experimentation (an SCP capping which, and how large, EC2 instance types can be launched, preventing runaway cost from an experiment gone wrong) — each OU's guardrails matched to that environment's actual risk profile.
Workflow
- Set up an AWS Organization with a management account (used for organization-wide administration and consolidated billing, ideally not for running actual workloads). 2) Design an Organizational Unit structure matching your company's actual environment/team boundaries (e.g. by environment: Production/Dev/Sandbox, or by business unit). 3) Define SCPs implementing company-wide non-negotiable guardrails (e.g. preventing CloudTrail from being disabled, restricting allowed Regions) and attach them at the appropriate level (root for universal rules, specific OUs for environment-specific rules). 4) Consider AWS Control Tower if starting a new multi-account setup, since it automates much of this best-practice structure rather than assembling it manually.
Example
A financial services company's AWS Organization has an SCP attached at the root level that denies the ability to disable CloudTrail or delete the S3 bucket where audit logs are centrally stored, in ANY account in the organization — this guardrail exists specifically so that even a compromised or rogue account administrator with full IAM admin rights within their own account cannot cover their tracks by disabling audit logging, since the SCP's deny is enforced above and independent of that account's own IAM permissions entirely.
Real-world usage
AWS Organizations with SCPs is the standard AWS recommendation for any company operating more than a handful of AWS accounts, extensively documented in AWS's own multi-account security best practices; AWS Control Tower is commonly used by companies setting up a new multi-account environment from scratch specifically to avoid manually assembling and maintaining Organizations, SCPs, and centralized logging themselves.
Trade-offs
A single AWS account is simpler to operate for a small team or early-stage project, but offers no blast-radius isolation between different teams/environments/projects sharing it, and provides no centrally-enforced guardrail mechanism beyond whatever IAM discipline each person maintains individually. A multi-account Organization with SCPs provides genuine isolation and centrally-enforced non-negotiable guardrails, at the cost of real setup and ongoing operational complexity — appropriate once a company has grown enough that blast-radius isolation and centralized governance become worth that complexity, not a day-one requirement for every project.
Visual explanation
Picture a tree structure: the Organization's root at the top, branching into Organizational Units (OUs) — perhaps 'Production,' 'Development,' and 'Sandbox' — each containing individual member AWS accounts. An SCP attached at the root applies to every account in the entire organization; an SCP attached to just the 'Sandbox' OU applies only to accounts within that specific branch — letting you apply broader guardrails at the top and progressively more specific ones deeper in the tree.
Advantages
- —
SCPs enforce company-wide security guardrails that no individual account's IAM permissions can override, providing a genuine, centrally-enforced security boundary
- —
Multiple accounts provide strong blast-radius isolation — a mistake or compromise in one account doesn't directly expose resources in another
- —
Consolidated billing gives unified cost visibility with per-account breakdown, plus volume discount benefits applying across combined organizational usage
- —
AWS Control Tower automates a well-architected multi-account setup rather than requiring manual assembly of the underlying primitives
Disadvantages
- —
Multi-account architectures add real operational complexity — cross-account access, shared resources, and centralized logging all require deliberate design rather than being automatic
- —
Poorly designed SCPs can accidentally block legitimate, necessary actions across an entire OU, and debugging 'why is this denied even though my IAM policy allows it' requires knowing to check SCPs specifically, not just the account's own IAM policies
- —
Setting up and maintaining a multi-account structure well is a genuine skill investment, not something to take on prematurely for a small team with simple needs
- —
SCPs can only restrict, never grant permissions — a common point of confusion for teams expecting them to work like a typical IAM policy that can also add access
Common mistakes
- —
Expecting an SCP to grant permissions the way an IAM policy does — SCPs only ever restrict the maximum available permission, they never grant anything on their own
- —
Attaching an overly broad, poorly tested SCP at the organization root and accidentally blocking a legitimate, necessary action across every single account in the organization at once
- —
Not understanding that an explicit SCP Deny overrides even a member account's own AdministratorAccess IAM policy, leading to confusing 'why can't the account admin do this' support tickets that require checking SCPs specifically to resolve
- —
Running actual production workloads directly in the Organization's management account instead of keeping it dedicated to organization-wide administration and billing, mixing concerns that should stay separate
- —
Building a multi-account structure prematurely for a very small team/project where the added complexity isn't yet justified by any real blast-radius or governance need
In the AWS Console
- 1
AWS Console → AWS Organizations → Create organization
Create the organization from your intended management account, then invite or create member accounts.
Reserve the management account for organization-wide administration and billing only — avoid running actual application workloads directly in it.
- 2
Organizations → AWS accounts → Organize accounts
Create Organizational Units matching your structure (e.g. Production, Development, Sandbox) and move member accounts into the appropriate OU.
Plan your OU structure around how you'll actually want to apply different SCPs to different groups of accounts — this structure is the basis for all subsequent policy targeting.
- 3
Organizations → Policies → Service control policies → Create policy
Write the SCP JSON (structurally similar to an IAM policy) and attach it to the root, a specific OU, or an individual account.
Test new SCPs against a non-critical account or OU first — an overly broad deny attached at the root can simultaneously affect every account in the organization.
🎤 Interview questions
What's the fundamental difference between an SCP and an IAM policy? (Listen for: SCP sets the maximum available permission boundary for an account/OU and only ever restricts, never grants; IAM policy attached within an account actually grants specific permissions, but can never exceed what applicable SCPs allow.)
Why would a company use multiple AWS accounts instead of one account with many IAM users/roles? (Listen for: blast-radius isolation between teams/environments/projects, centrally-enforced guardrails via SCPs that no in-account IAM policy can override, and cleaner cost attribution.)
Can an account's own AdministratorAccess IAM policy override a Service Control Policy? (Listen for: no — SCPs are evaluated above and independent of the account's own IAM policies; an explicit SCP deny always wins regardless of in-account permissions.)
What does AWS Control Tower add on top of raw AWS Organizations? (Listen for: automates setting up a well-architected multi-account landing zone — pre-configured OUs, baseline SCPs, centralized logging, self-service account provisioning — rather than assembling these manually.)
How would you design an SCP structure to ensure CloudTrail logging can never be disabled anywhere in the company's AWS footprint? (Listen for: attach an SCP denying the specific CloudTrail-disabling actions at the Organization's root level, so it applies to every account regardless of that account's own IAM permissions.)