AWS SCPs Explained: The Key to Cloud Security


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.
🚨 Traditional Setup (Without AWS Organizations)
If you’re just using a single AWS account with IAM users:
You control access only through IAM policies.
If the IAM policy allows
ec2:RunInstances
, the user can launch any EC2 instance type unless you explicitly restrict it in the IAM policy.But here's the problem:
IAM policies get complex fast.
They're applied per user/role, so enforcing org-wide rules (like "No one launches
p4d.24xlarge
") is hard.Mistakes in IAM policies = unwanted actions.
🔍 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.
🏗️ Understanding the Structure
Here’s how AWS Organizations and SCPs tie together:
Management Account: The root controller. SCPs do not apply here.
Root OU: The top-level container for all your accounts and OUs.
Organizational Units (OUs): Logical groups of AWS accounts (e.g., Dev OU, Prod OU).
Member Accounts: Actual AWS accounts under the OUs.
Now, SCPs can be attached to:
The Root OU
Any OU
Any Member Account
Permissions flow downward, and denies stack. For example:
Root OU: Allow All
Dev OU: Deny EC2
Account A (under Dev): Inherits Deny EC2
So, even if Account A's IAM says EC2:Allow, SCP says no, and EC2 access is blocked.
🧪 Arjun Sets the Guardrails
To prevent budget leaks in the Dev OU, Arjun creates a simple SCP:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
He applies it to the Dev OU.
Now, no one in any account under Dev can launch EC2—even if IAM says yes.
Later, he wants only CloudWatch and S3 access in a testing environment. He writes an Allow List SCP:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:*",
"s3:*"
],
"Resource": "*"
}
]
}
If something isn’t on this allow list? It’s implicitly denied.
🎓 What You Need to Know for the SAA Exam
Here’s what AWS SAA aspirants like Arjun should remember:
Concept | Meaning |
SCPs do NOT apply to Management Account | Always full access |
SCPs are guardrails | They don’t grant permissions—just limit them |
Explicit Deny wins | Even if IAM allows something, SCP can deny it |
SCPs apply at OU and Account level | You can scope control broadly or narrowly |
Use with IAM for full control | IAM = 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
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!