🔐 What is SCP in AWS?

SCP (Service Control Policy) is a policy type used in Amazon Web Services (AWS) under AWS Organizations.

👉 It sets maximum permission boundaries for AWS accounts in an organization.

It does NOT grant permissions.
It only limits what IAM users/roles can do, even if IAM allows it.

🏢 Where SCP is Used?

SCP is used only with:

• AWS Organizations

• Applied to:

  • Organization Root

  • Organizational Units (OUs)

  • Individual AWS Accounts

🆚 SCP vs IAM Role vs IAM Policy

🎯 Simple Example

Imagine:

• IAM Policy says: "Allow EC2 full access"

• SCP says: "Deny EC2 in this account"

👉 Final result = EC2 access denied

Because:

🔥 SCP is the guardrail. IAM works inside that guardrail.

🤔 Why Was SCP Introduced?

Before SCP:

• Large companies had 100+ AWS accounts

• Developers could accidentally:

  • Delete CloudTrail

  • Disable security services

  • Launch costly services

  • Create resources in wrong region

AWS needed:

✔ Centralized control
✔ Security guardrails
✔ Compliance enforcement
✔ Cost control

So AWS introduced SCP inside AWS Organizations.

📌 When Do We Use SCP?

1️⃣ Restrict AWS Regions

Example: Allow only ap-south-1

2️⃣ Block Dangerous Services

Example:

• Deny iam:*

• Deny organizations:LeaveOrganization

3️⃣ Prevent Root User Misuse

Deny certain actions for all accounts.

4️⃣ Compliance & Governance

Force:

• CloudTrail always enabled

• Prevent deleting security tools

🏗 Real DevOps Example (Enterprise Setup)

Company Structure:

Root
 ├── Prod OU
 ├── Dev OU
 ├── Sandbox OU

SCP Example:

• Dev OU → Deny RDS creation

• Sandbox → Allow only limited services

• Prod → Deny region except Mumbai

🧠 Important Rule (Interview Gold)

Effective permission =

IAM Allow
AND
SCP Allow
AND
No Explicit Deny anywhere

If SCP denies → ❌ Access denied (even for Admin role)

🚨 Key Point Most People Miss

SCP affects:

• IAM users

• IAM roles

• Even root user

But:

• It does NOT affect management account (by default)

🎯 Final One-Line Understanding

IAM gives permissions.
SCP defines the maximum allowed boundary for the entire account.

Q. So SCP is above IAM roles and policies, correct?

✅ Yes — in short:

👉 SCP sits on top of IAM roles and policies.

Think of it like this:

SCP  →  Maximum allowed limit (Org level guardrail)
IAM  →  Grants actual permissions (Account level)

🔑 Final Permission Rule:

Access is allowed only if:

• IAM policy = Allow ✅

• SCP = Allow ✅

• No explicit deny ❌

If SCP denies → Access denied, even if IAM role says Allow.

🧠 1-Line Interview Answer:

SCP defines the maximum permission boundary at the organization level, while IAM roles and policies grant permissions within that boundary.

That's it. 🔥

🔥 Real-Time SCP JSON Example + Where It’s Used

🎯 Scenario 1: Restrict Regions (Enterprise Governance)

Company wants all accounts to use only Mumbai region (ap-south-1)

✅ SCP JSON

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllRegionsExceptMumbai",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "route53:*",
        "cloudfront:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "ap-south-1"
        }
      }
    }
  ]
}

📌 Where It’s Used?

• Created in AWS Organizations

• Attached to:

  • Root

  • OU (e.g., Prod OU)

  • Specific AWS Account

🎯 Scenario 2: Prevent Developers from Deleting Security Logs

Company wants to prevent deletion of:

• CloudTrail

• Config

• GuardDuty

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenySecurityServiceDeletion",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "config:DeleteConfigRule",
        "guardduty:DeleteDetector"
      ],
      "Resource": "*"
    }
  ]
}

🏢 Real Enterprise Usage Example

Structure in Amazon Web Services Organization:

Root
 ├── Prod OU
 ├── Dev OU
 ├── Sandbox OU

💡 Why SCP Is Used?

✔ Centralized governance
✔ Cost control
✔ Security guardrails
✔ Compliance enforcement
✔ Prevent root misuse

🎯 Interview-Ready 2-Min Answer

Service Control Policy (SCP) is a policy type in AWS Organizations that defines the maximum permission boundary for AWS accounts. It does not grant permissions but restricts what IAM users and roles can do within member accounts.

SCPs are applied at the Organization root, OU, or account level. They are mainly used in multi-account enterprise environments to enforce governance, security, and compliance controls centrally.

For example, we can use SCP to restrict AWS regions to only ap-south-1, prevent deletion of CloudTrail logs, block certain high-cost services, or deny IAM modifications in production accounts.

Even if an IAM role has AdministratorAccess, if SCP denies an action, the request will be blocked. So effective permission is the intersection of IAM policy and SCP.

In real enterprise setups, SCP acts as an organizational guardrail, while IAM provides account-level access control.

🔥 SCP vs Permission Boundary vs IAM Policy (Clear Comparison)

🧠 Simple Understanding

SCP → Maximum limit for whole account
Permission Boundary → Maximum limit for specific IAM role/user
IAM Policy → Grants actual permissions

🔑 Final Access Formula:

Access Allowed Only If:

IAM Allow
AND Permission Boundary Allow
AND SCP Allow
AND No Explicit Deny

🔍 Debugging “Access Denied” Due to SCP

When you see:

AccessDeniedException

Follow this step-by-step approach:

✅ Step 1: Check IAM Policy

Go to:
IAM → User/Role → Permissions

Confirm:

• Is the action allowed?

• Any explicit deny?

✅ Step 2: Check Permission Boundary

If attached:
IAM → Role → Permission Boundary
Ensure the boundary allows the action.

✅ Step 3: Check SCP (Most People Miss This)

Go to:
AWS Organizations
→ Accounts → Select Account
→ Policies → Service Control Policies

Look for:

• Explicit Deny

• Region restriction

• Service block

🚨 Real Debug Tip (Production Level)

Run:

aws organizations describe-effective-policy \
--policy-type SERVICE_CONTROL_POLICY \
--target-id <account-id>

This shows effective SCP applied.

🔥 Real-Time Production Incident Example (DevOps Scenario)

🏢 Scenario

Company Structure:

Root
 ├── Prod OU
 ├── Dev OU

SCP attached to Prod OU:

{
  "Effect": "Deny",
  "Action": "ec2:TerminateInstances",
  "Resource": "*"
}

💥 Incident

A DevOps engineer tries to terminate an EC2 instance in production during a scaling issue.

Even with:

• AdministratorAccess role

Result:

AccessDenied

🧠 What Happened?

SCP explicitly denied ec2:TerminateInstances.

IAM allowed it.
But SCP overruled it.

🎯 Why Company Did This?

To:

• Prevent accidental production shutdown

• Protect critical systems

• Enforce change management process

Only break-glass account had no SCP restriction.

🔥 Another Real Enterprise Example (Cost Control)

SCP attached to Sandbox OU:

{
  "Effect": "Deny",
  "Action": [
    "rds:*",
    "redshift:*"
  ],
  "Resource": "*"
}

Purpose:

• Prevent developers from launching expensive databases.

Saved company thousands per month.

🎯 Interview-Ready Punch Line

SCP is an organization-level guardrail that restricts the maximum permissions for AWS accounts. It works above IAM and permission boundaries. During debugging, if IAM and boundary look correct but access is still denied, SCP is usually the root cause.