AWS Organizations Service Control Policies

Definition

Service Control Policies (SCPs) are organization-wide permission policies that define the maximum permissions available in AWS accounts. SCPs are not grants (they don’t give access); they are permission boundaries that restrict what can be done even if an IAM policy grants permission.

How SCPs Work

Permission Boundary Model:

• IAM policies grant permissions
• SCPs define maximum allowed permissions
• Final permission = IAM policy ∩ SCP
• If SCP denies, even IAM allow is blocked

Example:

• SCP denies all iam:DeleteUser
• Account admin grants IAM user iam:DeleteUser permission
• Result: User cannot delete users (SCP boundary blocks it)

Organizational Unit (OU) Hierarchy

Root Organization:

• Master account for billing and Organizations management
• SCPs at root level apply to all accounts

Organizational Units (OUs):

• Groupings of accounts (production, development, security, etc.)
• SCPs at OU level apply to all accounts in that OU
• Child OUs inherit parent SCP policies

Inheritance Example:

Root
├─ SCP: Prevent disabling CloudTrail
├─ Production OU
│  ├─ SCP: Deny region changes
│  ├─ Account A (inherits both SCPs)
│  └─ Account B (inherits both SCPs)
└─ Development OU
   ├─ SCP: Allow any action
   └─ Account C (inherits Root SCP only)

Common SCP Patterns

Preventive Controls:

• Deny disabling CloudTrail or Config
• Deny deleting CloudWatch Logs
• Deny root account access key creation
• Deny disabling MFA
• Deny changing IAM policies

Regional Controls:

• Restrict to approved regions (us-east-1, eu-west-1 only)
• Prevent global service access in restricted regions

Compliance Controls:

• Deny unencrypted S3 buckets
• Deny public RDS instances
• Deny unencrypted EBS volumes

Cost Controls:

• Deny expensive instance types
• Limit EC2 purchasing to Savings Plans only

SCP vs IAM Policy

Common Mistakes

Mistake 1: Using SCPs instead of IAM policies. SCPs don’t grant access; IAM policies must still grant permissions.

Mistake 2: Writing overly restrictive SCPs. Balance security and operational flexibility; over-restriction breaks deployments.

Mistake 3: Not planning OU structure before rolling out SCPs. Redo OU structure with SCPs in place causes rework.

Implementation Timeline

Week 1: Planning

• Audit current permissions across accounts
• Design OU structure
• Identify desired SCP policies

Week 2-3: Development

• Test SCPs in non-critical account
• Iterate on policy logic
• Document exceptions

Week 4+: Rollout

• Apply to development accounts first
• Monitor for issues
• Roll out to production accounts

Related AWS Services

• AWS Organizations (multi-account management)
• IAM (identity and access management)
• AWS CloudTrail (audit logging of SCP denials)
• AWS Config (compliance checking)

Related FactualMinds Content

• Service Control Policies: AWS Governance Guide
• Cloud Security