Service Control Policies (SCPs) & AWS Organizations

Overview

AWS Organizations enables centralized management of multiple AWS accounts, while Service Control Policies (SCPs) provide the guardrails that define the maximum permissions across those accounts. Together, they form the foundation of enterprise-scale AWS governance.

SCPs don't grant permissions - they set boundaries. Even if an IAM policy allows an action, an SCP can restrict it. This makes SCPs the ultimate "permission ceiling" for your organization, ensuring that no matter what IAM policies exist, certain actions can never be performed.

For the SAA-C03 exam, understanding how SCPs interact with IAM policies and the organizational hierarchy is critical. Questions often test whether you understand that SCPs are preventive guardrails that cannot be overridden.

Key Principle

SCPs set the maximum available permissions - they don't grant permissions themselves. Effective permissions = IAM Policies INTERSECTED WITH SCPs. If either denies an action, the action is denied.

Exam Tip

Remember: SCPs never affect the management account, only member accounts. Also, SCPs don't affect service-linked roles. These are common exam distractors.

Architecture Diagram

SCPs and Organizations Hierarchy — Figure 1: AWS Organizations hierarchy showing how SCPs are inherited through OUs

Key Concepts

AWS Organizations

AWS Organizations is a free service for centrally managing multiple AWS accounts.

Key Features:

Consolidated Billing: Single payment method for all accounts
Centralized Management: Create, organize, and manage accounts
Policy-Based Governance: Apply SCPs and other policy types
Account Automation: Programmatic account creation

Components:

Organization: The root container for all accounts
Root: Top of the hierarchy (not the root user)
Organizational Units (OUs): Logical groupings of accounts
Accounts: Individual AWS accounts (management + members)

Service Control Policies (SCPs)

Service Control Policies

SCPs are organization policies that define the maximum permissions for member accounts.

Key Characteristics:

Boundary Policies: Set limits, don't grant permissions
Inherited: Flow down through the OU hierarchy
Cumulative Effect: All applicable SCPs must allow an action
JSON Format: Same syntax as IAM policies

What SCPs Control:

API actions (Allow/Deny)
Resources (with full ARN support as of 2025)
Conditions (IP, tags, regions, etc.)

2025 SCP Enhancements

New SCP Capabilities (2025)

AWS now supports full IAM policy language in SCPs:

Conditions: Use any IAM condition keys
Resource ARNs: Specify individual resources
NotAction with Allow: More flexible allow statements
NotResource: Exclude specific resources
Wildcards: Use * anywhere in action strings

This enables much more granular control than before!

SCP Inheritance

SCP Inheritance Model

SCPs are inherited through the organizational hierarchy:

How It Works:

SCPs attached to root apply to all OUs and accounts
SCPs attached to an OU apply to all child OUs and accounts
SCPs attached directly to an account apply to that account
All applicable SCPs must allow an action for it to be permitted

Effective Permissions:

Effective Permissions =
  Root SCPs ∩ OU SCPs ∩ Account SCPs ∩ IAM Policies

If any SCP in the path denies an action, it's denied - regardless of IAM policies.

SCP Inheritance Example

Level	SCP	Effect
Root	Allow: ec2:, s3:, rds:*	Maximum permissions for org
Production OU	Deny: ec2:TerminateInstances	Cannot terminate instances
Account A (in Production)	No additional SCPs	Inherits: Allow EC2/S3/RDS, Cannot terminate

What SCPs Don't Affect

SCP Limitations

SCPs do NOT apply to:

Management account - Always exempt from SCPs
Service-linked roles - Used by AWS services internally
Resource-based policies - SCPs only affect principals, not resources
Actions performed by AWS services on your behalf

These exceptions are frequently tested on the exam!

How It Works

Deny List vs Allow List Strategies

SCP Evaluation Flow — Figure 2: How SCPs are evaluated with IAM policies to determine effective permissions

Deny List Strategy (Recommended)

Start with Allow, add explicit Denies

How It Works:

Attach FullAWSAccess policy (allows everything)
Add explicit Deny statements for restricted actions
New AWS services are automatically available

Benefits:

Simpler to maintain
New services work by default
Easier to understand what's blocked

Best For: Most organizations

Allow List Strategy

Only allow explicitly permitted actions

How It Works:

Remove FullAWSAccess policy
Only allow specific services/actions
Everything else is implicitly denied

Challenges:

Must update for every new AWS service
Risk of blocking legitimate workloads
More complex to maintain

Best For: Highly regulated industries (finance, healthcare) requiring strict control

Common SCP Patterns

Pattern 1: Deny Specific Regions

JSONDeny All Actions Outside Approved Regions

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnapprovedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2",
            "eu-west-1"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/OrganizationAdminRole"
        }
      }
    }
  ]
}

Pattern 2: Protect Security Services

JSONPrevent Disabling CloudTrail and Config

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectCloudTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ProtectConfig",
      "Effect": "Deny",
      "Action": [
        "config:DeleteConfigRule",
        "config:DeleteConfigurationRecorder",
        "config:DeleteDeliveryChannel",
        "config:StopConfigurationRecorder"
      ],
      "Resource": "*"
    }
  ]
}

Pattern 3: Require Encryption

JSONRequire S3 Encryption

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnencryptedS3Objects",
      "Effect": "Deny",
      "Action": "s3:PutObject",
      "Resource": "*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption": "true"
        }
      }
    }
  ]
}

Pattern 4: Prevent Public Access

JSONPrevent Public S3 Buckets

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPublicBucketACL",
      "Effect": "Deny",
      "Action": [
        "s3:PutBucketPublicAccessBlock",
        "s3:DeletePublicAccessBlock"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/SecurityAdminRole"
        }
      }
    }
  ]
}

Pattern 5: Restrict Root User Actions

JSONDeny Root User Actions (Except Specific)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootUser",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    }
  ]
}

Recommended OU Structure

OU	Purpose	SCP Focus
Security	Log Archive, Audit, Security Tools	Protect security resources, deny deletions
Infrastructure	Networking, Shared Services	Protect shared resources, limit modifications
Workloads/Production	Production applications	Deny dangerous actions, require encryption
Workloads/SDLC	Dev, Test, Staging	More permissive, allow experimentation
Sandbox	Developer experimentation	Budget limits, region restrictions, minimal guardrails
PolicyStaging	Test new SCPs before rollout	Test policies safely
Transitional	Migrating/acquired accounts	Temporary permissive policies

Use Cases

Use Case 1: Region Restriction for Data Sovereignty

Scenario: European company must ensure all data stays in EU regions for GDPR compliance.

Solution:

Create SCP denying actions outside EU regions
Attach to Production and SDLC OUs
Except global services (IAM, Route 53, CloudFront)

Use Case 2: Prevent Accidental Termination

Scenario: Operations team accidentally terminated production instances.

Solution:

Create SCP denying ec2:TerminateInstances for production OU
Create exception role for authorized terminations
Require MFA for the exception role

Use Case 3: Security Service Protection

Scenario: Ensure CloudTrail cannot be disabled by any user in any account.

Solution:

Create SCP denying CloudTrail modification actions
Attach to root of organization
Even account admins cannot bypass this

Use Case 4: Sandbox Budget Control

Scenario: Developers need freedom to experiment but costs must be controlled.

Solution:

Create Sandbox OU with permissive SCPs
Add SCP preventing expensive instance types
Restrict to single region for cost visibility

Best Practices

SCP Best Practices

Use Deny List Strategy - Start permissive, add explicit denies
Test Before Applying - Use PolicyStaging OU first
Document All SCPs - Clear naming and descriptions
Use Conditions Wisely - Leverage 2025 condition support
Create Exception Roles - Don't paint yourself into a corner
Apply to OUs, Not Accounts - Easier to manage at scale
Protect Security Services - CloudTrail, Config, GuardDuty
Monitor with CloudTrail - Audit SCP-denied actions

OU Best Practices

Function Over Org Chart - Organize by compliance needs, not reporting structure
Keep Hierarchy Shallow - AWS supports 5 levels, but 2-3 is usually enough
Separate Prod from Non-Prod - Different security requirements
Create Sandbox OUs - Safe experimentation space
Use Transitional OUs - For acquisitions and migrations
Don't Over-Complicate - Simpler hierarchies are easier to maintain

Common Exam Scenarios

Exam Scenarios

Scenario	Solution	Why
Prevent all users from disabling CloudTrail	SCP denying cloudtrail:StopLogging at root	SCPs are preventive guardrails that cannot be overridden
Allow EC2 in us-east-1 only	SCP with region condition	Conditions can restrict to specific regions
User has IAM admin access but cannot launch EC2	SCP is denying EC2 actions	SCPs limit maximum permissions, even for admins
Management account can still perform denied action	Expected behavior	SCPs do not affect the management account
Need to test new SCP before production	Apply to PolicyStaging OU first	Test impact on non-production accounts
Lambda function denied by SCP but it uses service-linked role	Service-linked roles are exempt	SCPs do not affect service-linked roles
Acquired company needs temporary permissive access	Place in Transitional OU	Minimal restrictions during migration
Consolidate billing across 10 accounts	AWS Organizations consolidated billing	Single payment method for all member accounts

Common Pitfalls

Pitfall 1: Locking Yourself Out

Mistake: Applying restrictive SCP without exception role.

Why it's dangerous:

Cannot undo the SCP if you denied iam:* actions
May need AWS Support to recover
Production workloads may fail

Correct Approach:

Always create exception/break-glass roles
Test SCPs in staging OU first
Include conditions to exempt specific roles

Pitfall 2: Forgetting Management Account Exemption

Mistake: Assuming SCPs protect the management account.

Why it matters:

Management account is NEVER affected by SCPs
Security controls must be applied differently
Exam frequently tests this knowledge

Correct Approach:

Minimize workloads in management account
Use additional IAM policies for management account
Restrict who can access management account

Pitfall 3: Not Understanding Inheritance

Mistake: Expecting SCP at lower level to override higher level deny.

Why it fails:

SCPs are cumulative (AND logic)
All SCPs in path must allow the action
Cannot override parent deny with child allow

Correct Approach:

Plan hierarchy carefully before implementing
Use explicit allows at root, denies at lower levels
Understand inheritance flows down, not up

Pitfall 4: Using Allow List in Fast-Moving Environment

Mistake: Using allow list strategy when new services needed frequently.

Why it's problematic:

Every new AWS service is blocked by default
Teams can't use new features without SCP updates
Creates bottleneck and friction

Correct Approach:

Use deny list strategy (block specific actions)
Reserve allow list for highly regulated environments
Automate SCP updates if allow list is required

Test Your Knowledge

Which of the following is NOT affected by Service Control Policies?

AIAM users in member accounts

BIAM roles in member accounts

CThe management account

DCross-account access to member accounts

An IAM user has AdministratorAccess policy, but cannot launch EC2 instances. What is the most likely cause?

How are SCPs evaluated when multiple SCPs apply to an account?

AMost specific SCP wins

BLast attached SCP wins

CAll SCPs must allow the action (AND logic)

DAny SCP allowing grants access (OR logic)

A company wants to test a new SCP before applying it to production accounts. What is the recommended approach?

AApply directly to root and monitor

BApply to management account first

CApply to a PolicyStaging OU with test accounts

DSCPs cannot be tested before deployment

Management

AWS Organizations

Core service for multi-account management and SCP deployment

Management

AWS Control Tower

Automated landing zone setup with pre-configured SCPs as guardrails

Security

IAM Access Analyzer

Validates SCP syntax and checks for policy issues before deployment

Management

AWS CloudTrail

Logs all API calls including those denied by SCPs for auditing

Management

AWS Config

Monitor organizational compliance and SCP effectiveness

Quick Reference

SCP Limits

SCP Service Limits

Limit	Value
Maximum SCPs per organization	1,000
Maximum SCPs per OU or account	5
Maximum SCP document size	5,120 characters
Maximum OU nesting depth	5 levels

SCP vs IAM Policy Comparison

SCP vs IAM Policies

Aspect	SCP	IAM Policy
Purpose	Set maximum permissions	Grant permissions
Scope	Organization/OU/Account	User/Group/Role
Grants Access	No - only restricts	Yes
Affects Management Account	No	Yes
Affects Service-Linked Roles	No	Limited
Inheritance	Yes - through OU hierarchy	No automatic inheritance

CLI Commands Reference

SHCommon AWS Organizations CLI Commands

# List all SCPs in organization
aws organizations list-policies --filter SERVICE_CONTROL_POLICY

# Get SCP content
aws organizations describe-policy --policy-id p-abc123def

# Create new SCP
aws organizations create-policy \
  --name "DenyUnapprovedRegions" \
  --description "Prevents use of unapproved regions" \
  --type SERVICE_CONTROL_POLICY \
  --content file://scp-deny-regions.json

# Attach SCP to OU
aws organizations attach-policy \
  --policy-id p-abc123def \
  --target-id ou-root-example

# Detach SCP from OU
aws organizations detach-policy \
  --policy-id p-abc123def \
  --target-id ou-root-example

# List OUs in organization
aws organizations list-organizational-units-for-parent \
  --parent-id r-abc1

# Move account to different OU
aws organizations move-account \
  --account-id 123456789012 \
  --source-parent-id ou-source \
  --destination-parent-id ou-destination

Common SCP Condition Keys

TEXTUseful SCP Condition Keys

aws:RequestedRegion       - Restrict by AWS region
aws:PrincipalArn         - Match principal ARN pattern
aws:PrincipalOrgID       - Ensure principal is in org
aws:PrincipalTag/*       - Match principal tags
aws:ResourceTag/*        - Match resource tags
aws:SourceIp             - Restrict by source IP
ec2:InstanceType         - Restrict instance types
s3:x-amz-server-side-encryption - Require encryption

Key Concepts

Service Control Policies (SCPs) & AWS Organizations

Overview

Key Principle

Architecture Diagram

Key Concepts

AWS Organizations

AWS Organizations

Service Control Policies (SCPs)

Service Control Policies

2025 SCP Enhancements

New SCP Capabilities (2025)

SCP Inheritance

SCP Inheritance Model

SCP Inheritance Example

What SCPs Don't Affect

SCP Limitations

How It Works

Deny List vs Allow List Strategies

Deny List Strategy (Recommended)

Allow List Strategy

Common SCP Patterns

Pattern 1: Deny Specific Regions

Pattern 2: Protect Security Services

Pattern 3: Require Encryption

Pattern 4: Prevent Public Access

Pattern 5: Restrict Root User Actions

Recommended OU Structure

Recommended OU Structure

Use Cases

Use Case 1: Region Restriction for Data Sovereignty

Use Case 2: Prevent Accidental Termination

Use Case 3: Security Service Protection

Use Case 4: Sandbox Budget Control

Best Practices

SCP Best Practices

OU Best Practices

Common Exam Scenarios

Exam Scenarios

Common Pitfalls

Pitfall 1: Locking Yourself Out

Pitfall 2: Forgetting Management Account Exemption

Pitfall 3: Not Understanding Inheritance

Pitfall 4: Using Allow List in Fast-Moving Environment

Test Your Knowledge

Related Services

AWS Organizations

AWS Control Tower

IAM Access Analyzer

AWS CloudTrail

AWS Config

Quick Reference

SCP Limits

SCP Service Limits

SCP vs IAM Policy Comparison

SCP vs IAM Policies

CLI Commands Reference

Common SCP Condition Keys

Further Reading

Related AWS Services