AWS Organizations – Beyond the Basics
A working engineer's guide to how Service Control Policies actually evaluate, how OU hierarchies inherit, and why an "effective permission" is never decided by IAM alone once accounts belong to an organization.
If you already know that AWS Organizations “lets you centrally manage multiple AWS accounts,” this article picks up one level higher. We’ll spend our time on how Service Control Policies actually combine with IAM to produce an effective permission, how policy inheritance flows down an OU tree, what delegated administration really changes about who can do what, and the governance mistakes that look fine in a small organization and become expensive the moment you have dozens of accounts. We’ll assume you’re operating with all features enabled rather than the legacy consolidated-billing-only mode, since that’s what unlocks SCPs, tag policies, and the rest of the governance surface this guide focuses on.
A fast recap of the multi-account model, framed for someone past the introductory pitch.
Organizations exists to solve a problem that shows up the moment a company operates more than a handful of AWS accounts: how do you apply consistent guardrails, consolidate billing, and delegate administrative capability without either granting every team root-equivalent access or manually replicating policy across every account by hand. A single AWS account with IAM alone has no concept of “accounts” as a governed unit at all — Organizations introduces that unit, plus a policy layer that sits above IAM rather than replacing it.
Full governance surface
Unlocks Service Control Policies, Resource Control Policies, tag policies, backup policies, and AI services opt-out policies alongside consolidated billing.
Legacy, billing-focused mode
Combines invoices and volume discounts across accounts but does not enable any of the policy types that let you actually govern what those accounts can do.
The vocabulary intermediate Organizations work depends on.
Management Account — the account that creates the organization; it has unique capabilities (managing consolidated billing, creating and inviting accounts, attaching policies) that cannot be delegated away in full, only in specific slices via delegated administration.
Member Account — any account belonging to the organization other than the management account itself; SCPs, tag policies, and other organization policies apply to member accounts, never to the management account.
Organizational Unit (OU) — a container used to group accounts (and other OUs) into a hierarchy, so policies can be attached once at an OU level and inherited by everything beneath it, rather than attached individually per account.
Root — the top-level container of the entire OU hierarchy; every account and OU exists somewhere beneath it.
Service Control Policy (SCP) — an organization-level policy that defines the maximum available permissions for accounts it’s attached to; it never grants permissions on its own, only limits what IAM policies within those accounts are allowed to grant.
How the OU tree, policies, and accounts fit together.
flowchart TB
Root["Root"]
Root --> OUSec["OU: Security"]
Root --> OUWork["OU: Workloads"]
Root --> OUSandbox["OU: Sandbox"]
OUWork --> OUProd["OU: Production"]
OUWork --> OUDev["OU: Development"]
OUSec --> AcctLog["Account: Log Archive"]
OUSec --> AcctSecTools["Account: Security Tooling"]
OUProd --> AcctProdApp["Account: Prod Application"]
OUDev --> AcctDevApp["Account: Dev Application"]
OUSandbox --> AcctSandbox["Account: Sandbox User"]
SCP1["SCP: Deny Region Restriction"] -.attached to.-> Root
SCP2["SCP: Deny IAM User Creation"] -.attached to.-> OUProd
Any account, or OU, can have multiple organization policies attached simultaneously, and any account inherits every policy attached anywhere above it in the tree, all the way up to root — this is what makes root-level attachment the place for organization-wide non-negotiables, and lower-OU attachment the place for guardrails specific to that group of accounts.
The single most misunderstood mechanic in Organizations — SCPs restrict, they never grant.
A brand-new organization ships every account with a default SCP called FullAWSAccess, which simply allows everything — meaning by default, SCPs are invisible and IAM within each account behaves exactly as it would without Organizations at all. The moment you attach a more restrictive SCP, you are narrowing that ceiling, not adding new capability.
Think of IAM policies as the specific keys an employee is issued, and an SCP as the set of doors that physically exist in the building at all. Giving someone a key to a door that doesn’t exist does nothing — no matter how permissive their IAM policy is, an SCP that removes a service entirely removes the door, and the key becomes irrelevant. Conversely, the SCP alone opens no doors for anyone; it only defines which doors could ever be walked through.
The effective permission for any action in a member account is the intersection of what IAM allows and what every SCP in effect (from root down to the account) allows. An explicit Deny in an SCP anywhere in that chain cannot be overridden by an Allow in IAM, or even by a more permissive SCP lower in the tree — deny statements in SCPs are absolute within their scope.
Attaching an SCP to the management account itself has no effect — SCPs never apply to the management account, only to member accounts. Teams sometimes discover this only after wondering why a supposedly organization-wide restriction doesn’t seem to apply when tested from the management account.
How an account actually comes to exist inside — or leave — an organization.
sequenceDiagram
participant Admin as Organization Admin
participant Org as AWS Organizations
participant New as New/Invited Account
Admin->>Org: Create account OR invite existing account
Org->>New: Provision account / send invitation
New-->>Org: Account joins organization (accepts invite, if invited)
Org->>New: Apply inherited SCPs, tag policies from OU placement
Admin->>Org: Move account into target OU
Org->>New: Re-evaluate inherited policies for new OU position
Accounts can be created directly through Organizations (provisioning a brand-new account under the management account’s ownership) or invited (bringing an existing standalone account into the organization, which requires that account’s owner to accept). Leaving an organization is possible but has real prerequisites — the account must meet certain configuration requirements (such as having its own valid payment method) before it can be removed, since it stops being covered by consolidated billing at that point.
Two competing strategies for structuring SCPs, and why most mature organizations converge on one.
Deny List Strategy
- Keep the default
FullAWSAccessallow-everything policy attached, and add specificDenystatements for things you want to prohibit - Simpler to start with, but requires anticipating every risky action you want to block
Allow List Strategy
- Remove the default full-access policy and explicitly enumerate only the services and actions accounts are permitted to use
- Stronger guarantee (nothing works unless explicitly allowed), but higher maintenance overhead as legitimate new use cases require policy updates
Regardless of strategy, SCPs commonly enforce non-negotiable guardrails such as restricting which AWS Regions can be used at all, preventing member accounts from leaving the organization unilaterally, blocking modification or deletion of specific security-critical resources (like a centrally managed CloudTrail trail), and requiring that certain IAM actions (such as creating new IAM users, in favor of federated access) never happen at all.
SCPs get most of the attention, but they aren’t the only organization policy type.
Resource Control Policies (RCPs) — a newer policy type working similarly to SCPs but constraining what resource-based policies (like an S3 bucket policy) can grant, regardless of the identity making the request — closing a gap where an overly permissive resource policy could otherwise be exploited even by a principal outside the organization entirely.
Tag Policies — enforce consistent tagging standards (required keys, allowed values) across accounts, which matters enormously for cost allocation reporting and automated governance tooling that depends on tags being predictable rather than freeform.
Backup Policies — centrally define AWS Backup plans and apply them across accounts and OUs, ensuring a consistent backup cadence and retention standard without each account team configuring backup independently (or forgetting to).
Why RCPs Matter Alongside SCPs
An SCP restricts what an identity inside your organization can do; an RCP restricts what a resource’s own policy can grant to anyone, including external accounts. A public S3 bucket policy misconfiguration is exactly the kind of risk RCPs are designed to close that SCPs, being identity-focused, cannot.
Spreading operational control without spreading management-account access.
Many AWS services that operate across an organization (GuardDuty, Security Hub, Config, CloudTrail, IAM Identity Center, and others) support designating a member account as a delegated administrator for that specific service. This lets a security team operate and configure that service organization-wide from a dedicated account, without ever needing management-account credentials — a meaningful separation of duties, since the management account’s blast radius if compromised is the entire organization.
Delegated administration is scoped per service — being the delegated admin for GuardDuty grants no special capability over Config or Security Hub unless separately delegated for those too. This granularity is intentional, letting different teams own different centralized services without any one team accumulating broad organizational control.
The financial mechanics underneath the governance layer.
All member accounts’ usage rolls up into a single invoice paid by the management account, and volume-based pricing discounts (as well as Reserved Instance and Savings Plan sharing benefits, when enabled) are calculated across the combined usage of the whole organization rather than per account in isolation — meaning an organization with many small accounts can reach volume discount tiers it would never individually qualify for.
Consolidated billing does not remove per-account cost visibility — Cost Explorer and Cost and Usage Reports can still break spending down by linked account, which is essential for internal chargeback or showback processes even when the actual invoice is unified.
Why most organizations don’t build their OU structure entirely from scratch.
AWS Control Tower is built on top of Organizations, providing a pre-built “landing zone” with a recommended baseline OU structure (typically including dedicated Security and Log Archive OUs), pre-configured SCPs known as guardrails, and automated account provisioning through an internal account factory. Teams commonly start with Control Tower precisely to avoid re-deriving a governance baseline that AWS has already codified based on common practice, then customize from there.
Typical Baseline OU Structure
A Security OU (housing log archive and security tooling accounts, tightly restricted), a Workloads OU split into Production and Development or Staging, and a Sandbox OU with looser guardrails for individual experimentation — is a common starting pattern that most landing zone designs, whether built manually or via Control Tower, converge toward.
Why the management account deserves disproportionate protection, and what SCPs can and can’t secure on their own.
- Management account hardening — since compromise of the management account potentially threatens the entire organization, it should have minimal day-to-day human access, strong MFA enforcement, and ideally be used almost exclusively for organization-level administrative tasks rather than everyday workloads.
- SCPs as guardrails, not primary controls — SCPs constrain what’s possible at the account level, but within the boundary they allow, ordinary IAM least-privilege practices are still entirely necessary; SCPs are a backstop, not a replacement for identity-level permission hygiene.
- Federated access over long-lived credentials — combining Organizations with IAM Identity Center for centralized human access, rather than individual IAM users per account, is the standard pattern for reducing long-lived credential sprawl across dozens of accounts.
An SCP that permits the EC2 service entirely still relies on IAM within that account to prevent an over-permissioned role from launching instances it shouldn’t. Guardrails narrow the ceiling; they do not enforce least privilege beneath it.
How to actually see what’s happening across an entire organization, not just one account at a time.
| Tool / Signal | What It Tells You | Watch For |
|---|---|---|
| Organization CloudTrail Trail | API activity across every member account, aggregated centrally, configured once from the management account | Ensure it’s actually enabled organization-wide — a per-account trail configuration defeats the purpose of centralized visibility |
| AWS Config Aggregator | Resource configuration and compliance state rolled up across accounts | Drift in one account’s baseline configuration relative to the rest often surfaces here first |
| Access Denied due to SCP (CloudTrail errorCode) | Requests blocked specifically by an SCP rather than by IAM | A spike in SCP-driven denials after a new policy rollout usually means the policy is broader than intended |
| Delegated admin activity logs | Actions taken by delegated administrator accounts for centralized services | Confirms delegated administration boundaries are actually being respected in practice, not just in configuration |
How OU structures and policies are actually provisioned and kept consistent at scale.
OU hierarchies, SCPs, and account creation are commonly managed through Infrastructure as Code, since a manually built OU tree with hand-attached policies becomes very difficult to audit or reproduce once an organization grows past a small number of accounts.
CloudFormation StackSets
Deploy a consistent CloudFormation stack (a baseline security configuration, a shared VPC pattern) across many accounts and OUs from a single operation, keeping infrastructure baselines consistent org-wide.
Account Factory / Automation
Whether through Control Tower’s account factory or custom automation, new accounts are commonly provisioned with a standard baseline (SCPs already inherited from OU placement, a starting set of IAM roles, logging already wired up) rather than starting from a blank account.
What a well-structured organization looks like — and the mistake that undermines account isolation entirely.
Account-per-workload isolation — using separate accounts as the primary security and billing boundary between workloads (rather than relying solely on IAM within one large shared account) limits blast radius and keeps cost attribution unambiguous.
OU structure mirroring risk tolerance, not org chart — grouping accounts by how much guardrail strictness they need (Production vs Sandbox) tends to age better than grouping by team names that reorganize over time.
Pattern
Treating SCPs as the only security control needed, and skipping IAM least-privilege work within member accounts because “the SCP already restricts things.”
Why It Fails
SCPs define a ceiling, not a floor — any permission the SCP allows is still available to be over-granted by a permissive IAM policy inside that account. An organization that never tightens IAM within accounts, relying entirely on broad SCP boundaries, still carries substantial risk of privilege misuse within whatever the SCP does permit.
What To Do Instead
Treat SCPs and RCPs as organization-wide non-negotiable guardrails, and continue applying ordinary least-privilege IAM practices within every account beneath them — the two layers are complementary, not substitutes for each other.
Advantages
- Centralized guardrails via SCPs and RCPs apply organization-wide without per-account manual configuration
- Consolidated billing unlocks combined volume discounts and shared RI/Savings Plan benefits
- Delegated administration separates operational control from management-account access
- OU-based inheritance scales policy management far better than per-account policy attachment
Disadvantages & Trade-offs
- The management account is a uniquely high-value target and its compromise threatens the entire organization
- SCPs restrict but never grant — they add real design complexity for permission troubleshooting (“is this an IAM problem or an SCP problem?”)
- An overly rigid allow-list SCP strategy adds ongoing maintenance overhead as legitimate needs evolve
- OU structure decisions made early are disruptive to change later, once dozens of accounts depend on the existing hierarchy
Harden the management account above all else
Minimize human access, enforce MFA, and avoid running everyday workloads in it — its compromise has organization-wide consequences.
Design the OU tree around guardrail needs, not team structure
Org charts change more often than the risk profile of Production versus Sandbox — structure around the latter.
Test new SCPs against a non-critical OU first
A broad or malformed SCP attached at root can lock every account in the organization out of a needed service simultaneously — validate against a limited scope before wide rollout.
Use delegated administration instead of sharing management-account access
Give security and operations teams the specific service-level control they need without expanding who can touch the management account itself.
Keep IAM least-privilege discipline regardless of SCP coverage
SCPs are a ceiling, not a substitute for tightening what’s actually granted within it.
Regulated industries enforcing Region restrictions
Financial services and healthcare organizations commonly use root-level SCPs to prevent any account from ever operating outside approved Regions, regardless of what an individual account administrator might otherwise configure.
Engineering sandboxes with loose guardrails
Technology companies frequently give individual engineers their own sandbox accounts under a permissive Sandbox OU, letting them experiment freely while still inheriting baseline security guardrails from higher in the tree.
Centralized security tooling via delegated administration
Large organizations commonly designate a dedicated Security Tooling account as delegated administrator for GuardDuty, Security Hub, and Config, giving the security team organization-wide visibility without management-account access.
FullAWSAccess SCP allows everything unless you’ve replaced or supplemented it with more restrictive policies.Carry This Forward
- SCPs restrict the ceiling of what’s possible — they never grant permissions on their own, and the effective permission is always the intersection with IAM.
- An explicit Deny anywhere in the OU chain from root to an account is absolute and cannot be overridden by IAM or a lower, more permissive SCP.
- SCPs never apply to the management account, which is why hardening that account matters disproportionately more than any single member account.
- RCPs, tag policies, and backup policies extend organization governance beyond identity-focused SCPs into resource policies, tagging, and backup consistency.
- Delegated administration lets teams operate centralized services organization-wide without expanding management-account access.
- Structure your OU tree around guardrail needs (Production vs Sandbox) rather than current team names, which change more often than risk tolerance does.
- Treat SCPs as a complement to IAM least-privilege practices, never a replacement for them.