AWS SCPs Explained: The Key to Cloud Security

Jay TilluJay Tillu
4 min read

Arjun had just finished setting up an AWS Organization for his growing startup. With one Management Account, a few OUs (Organizational Units) like Dev, Prod, and HR, and multiple Member Accounts, he felt on top of the world.

Until chaos struck.

Someone in the Dev account spun up a massive EC2 instance—one that wasn't budgeted for.

“How did this happen?” Arjun muttered, scrolling through logs.

The IAM permissions were fine. Each team only had what they needed. But there was nothing stopping them from doing anything within the scope of those permissions.

That’s when Arjun discovered the missing piece of the puzzle:

Service Control Policies (SCPs) — The ultimate permission boundaries for AWS accounts.


🧱 Step 1: Lay the Foundation with SCPs (Introduced in 2017)

SCPs were introduced in 2017 as part of AWS Organizations to help control what actions accounts in the organization are allowed to perform, regardless of their IAM permissions.

Think of SCPs like a master kill switch.
If IAM is the key to the door, SCPs decide whether the door exists at all.

Arjun read the official doc:

“SCPs don’t grant permissions. They only define the maximum permissions an account can use.”

He smiled.
“Perfect. Exactly what I need.”


🔍 What are SCPs?

Service Control Policies (SCPs) are like guardrails. They define what actions can or cannot be performed in any AWS account inside an Organization—regardless of what the IAM permissions say.

Think of IAM as the “yes or no” at the user level, and SCPs as the “yes or no” at the account or OU level.

If IAM allows something, but SCP denies it — it’s denied.
If IAM denies something, but SCP allows it — it’s still denied.

SCPs don’t grant permissions. They only set the maximum permissions.


IAM vs SCP – Why SCP Comes First

Arjun drew a simple diagram for his CTO:

IAMSCP
Grants Permissions?✅ Yes❌ No
Controls Who?Users, RolesEntire Account (incl. root)
Deny Capable?✅ Yes✅ Yes
Part of Org?❌ Optional✅ Requires AWS Org (all features)
Use CaseGive devs accessRestrict misuse at org/account level

IAM is local defense.
SCP is organization-wide governance.

That day, Arjun created the first SCP and attached it to the Dev Organizational Unit (OU):

jsonCopyEdit{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "ap-south-1"
        }
      }
    }
  ]
}

Outcome?
All accounts in the Dev OU were restricted to Mumbai (ap-south-1) — no matter what IAM role they had.


🧰 Real-World SCP Use Cases Arjun Implemented

GoalSCP Strategy
Restrict regionDeny aws:RequestedRegion != ap-south-1
Block expensive servicesDeny athena:*, redshift:*
Prevent IAM changes in ProdDeny iam:*
Stop root abuseDeny dangerous actions like kms:DeleteKey, ec2:TerminateInstances

🎓 What You Need to Know for the SAA Exam

Here’s what AWS SAA aspirants like Arjun should remember:

ConceptMeaning
SCPs do NOT apply to Management AccountAlways full access
SCPs are guardrailsThey don’t grant permissions—just limit them
Explicit Deny winsEven if IAM allows something, SCP can deny it
SCPs apply at OU and Account levelYou can scope control broadly or narrowly
Use with IAM for full controlIAM = access inside accounts, SCP = access boundaries across accounts

🚀 Why SCPs Matter in the Real World

  • Enforce security policies across all accounts.

  • Prevent accidental spending or risky actions.

  • Centralized compliance and control.

  • Useful in large enterprises, regulated industries, and multi-team setups.

Even if your team members are IAM users in one account today, as you grow, SCPs become the backbone of good cloud governance.


🧠 Final Words from Arjun

Arjun realized that without SCPs, managing access across AWS accounts was like locking doors but leaving the house wide open.

With SCPs in place, he now had complete clarity and centralized control—a must-have for any cloud architect aiming for scalability, security, and sanity.


Follow me for more such content

0
Subscribe to my newsletter

Read articles from Jay Tillu directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Jay Tillu
Jay Tillu

Hello! I'm Jay Tillu, an Information Security Engineer at Simple2Call. I have expertise in security frameworks and compliance, including NIST, ISO 27001, and ISO 27701. My specialities include Vulnerability Management, Threat Analysis, and Incident Response. I have also earned certifications in Google Cybersecurity and Microsoft Azure. I’m always eager to connect and discuss cybersecurity—let's get in touch!