SCP (Service Control Policies) & Hierarchy in AWS | Deep Dive.

SCP (Service Control Policies) & Hierarchy in AWS - Deep Dive.

Scope:

• Intro,
• Hierarchical structure,
• Inheritance and evaluation logic,
• Key constraints,
• Link to documentation,
• Overview of SCPs,
• Hierarchy and Inheritance,
• SCP Evaluation Logic,
• Order of Evaluation,
• Key Types of SCPs,
• Sample SCP Inheritance in Action,
• Common Use Cases,
• Architecture Diagram of SCP Hierarchy & Evaluation Flow,
• Best Practices.

Intro:

• In AWS Organizations, Service Control Policies (SCPs) act as guardrails. 
• Guardrails  define the maximum permissions for member accounts. 
• Guardrails  do not grant permissions.
•  Instead, Guardrails filter permissions, ensuring that even users with full administrator access in a member account cannot perform restricted actions. 

Hierarchical structure

SCPs are applied at three levels within an AWS Organization hierarchy: 

• Root: Applies to every account in the organization.
• Organizational Unit (OU): Applies to all accounts and child OUs within that specific container.
• Individual Account: Applies only to the specific member account. 

Inheritance and evaluation logic

The effective permissions for any account are the logical intersection of all policies in its parent path: 

• Top-Down cascading: Policies attached at the root flow down through the OU tree to the member accounts.
• Deny-First rule: An explicit Deny statement at any level—root, OU, or account—overrides any Allow statements at other levels.
• Requirement for explicit Allow: For a service or action to be permitted, it must be explicitly allowed by an SCP at every node in the direct path from the root down to the target account.
• Management account exemption: SCPs do not apply to the management (master) account of the organization; SCPs only restrict member accounts.

Key constraints

• Guardrails, not grants: Users must still have IAM policies granting them access. 
• If an SCP allows an action but an IAM policy does not, the action is denied.
• Default state: When twech enable SCPs, AWS automatically attaches the FullAWSAccess policy to the root, OUs, and accounts to ensure existing permissions are not immediately broken.
• Size and limit: Each policy is limited to 5,120 bytes, and twtecg can attach a maximum of 5 SCPs to any single organizational entity (root, OU, or account).

Link to documentation

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

Overview of SCPs

• Service Control Policies (SCPs) are organization-wide guardrails in AWS Organizations that define what actions are allowed or denied across AWS accounts,
• ...Regardless of what the IAM users, roles, or resource policies say.
• SCPs don’t grant permissions — they restrict them.
• Think of SCPs as the outer boundary of permissions an account can ever use.

 Hierarchy and Inheritance

SCPs operate within the AWS Organizations hierarchy:

NB:

• SCPs can be attached at any level (Root, OU, Account).
• SCPs apply downward through inheritance.

Level	SCP Effect		Inheritance
Root		Affects all accounts in the organization	Inherited by all
OU		Affects all accounts within that OU and nested OUs	Inherited downward
Account		Affects only that specific account	No further inheritance

NB:

Effective permissions = Intersection of all applicable SCPs × IAM × Resource policies.

 SCP Evaluation Logic

When AWS evaluates whether a request is allowed:

EffectivePermissions = (Org SCPs allow?) AND (IAM policy allows?) AND (Resource policy allows?)

NB:

That means a single Deny anywhere = Deny overall.

 Order of Evaluation:

1. Root SCP (if any)
2. OU-level SCPs (from top to bottom)
3. Account-level SCP (if attached)
4. IAM policies inside the account

NB:

Therefore, if any parent SCP denies an action, child SCPs can’t override that.

 Key Types of SCPs

Type	Description	Example
Deny List (restrictive)	Deny specific actions but allow all others	Deny ec2:TerminateInstances
Allow List (whitelist)	Allow specific actions only; deny everything else	Allow s3:* and ec2:Describe*
Hybrid	Mix of allow/deny statements	Allow ec2:*, deny ec2:Delete*

 NB:

• AWS recommends “Deny List” approach for manageability 
• — use SCPs to prevent dangerous or noncompliant actions, not to micromanage every permission.

Sample SCP Inheritance in Action

Imagine this setup:

Root SCP: Deny all access to billing

OU: Deny EC2:TerminateInstances

Account SCP: Allow EC2:*

NB:

An IAM role in the account has full EC2 permissions.

 Result:

• Even though the account SCP and IAM allow EC2 actions,
• EC2:TerminateInstances is still denied (because the OU SCP denies it),
• Billing actions are denied (because the Root SCP denies them).

 Common Use Cases

Use Case	Example SCP
Enforce region restrictions	Deny all actions not in us-east-2
Prevent accidental deletion	Deny s3:DeleteBucket
Enforce data residency	Deny use of non-compliant regions
Guardrails for dev accounts	Deny iam:* and restrict to t3.micro
Protect master payer account	Deny all except aws-portal:* and organizations:*

Architecture Diagram of SCP Hierarchy & Evaluation Flow

Effective permission = Root SCP ∩ OU SCP ∩ Account SCP ∩ IAM Policy

Best Practices

1. Use Root SCP sparingly – only for global, org-wide controls.
2. Apply Deny-based SCPs for key compliance rules.
3. Test SCPs with “dry-run” OUs or sandbox accounts first.
4. Name SCPs clearly (e.g., Deny-EC2-TerminateInstances).
5. Avoid redundant Denies – they can complicate debugging.
6. Document inherited SCPs per account for auditing clarity.