Learn how AWS RCPs Implement Security Boundaries Effectively

Arjun had just joined a fast-growing fintech startup as a Cloud Security Engineer.

His mission?
Secure the entire AWS infrastructure across dev, test, and production accounts.

The company was using AWS Organizations to manage accounts, and they already had Service Control Policies (SCPs) in place.

But something strange kept happening.

Despite the SCPs and strict IAM controls, devs were still managing to:

• Make Amazon S3 buckets public

• Share secrets across accounts

• Create grants in AWS KMS that nobody could trace

“How is this possible?!” Arjun thought.
“If SCPs are in place, how can they still do this?”

---

🔍 SCP vs RCP – What’s the Difference?

Before diving into the fix, let’s clear the confusion Arjun had.

So SCP = Identity guardrails. RCP = Resource guardrails.

---

🆕 AWS Introduced RCPs in December 2023

AWS realized that SCPs alone aren’t enough to prevent misconfigurations on resources.

That’s why in December 2023, they released Resource Control Policies (RCPs) — a new type of organization policy.

RCPs don’t care who is accessing. They care about what is being accessed, and how.

They’re like setting rules for a bank locker:

"Even if someone has the key, the locker itself won’t open unless it's within policy."

---

🚧 The Problem Arjun Faced

Arjun found an S3 bucket in a dev account with a policy that made it public.
IAM roles allowed it. SCP didn’t block it.
But it wasn’t safe.

“I need to make sure some resources can never go public — no matter what policy someone adds.”

That’s where RCPs came in.

---

🛠️ What Arjun Did

Arjun created an RCP like this:

{
  "Version": "2023-10-01",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "s3:PutBucketPolicy",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "o-xxxxxxxxxx"
        }
      }
    }
  ]
}

He attached it to the dev organizational unit (OU).

This RCP ensured that no bucket policy could ever allow access outside the organization—no matter what a developer tried.

🎯 Even if they had full admin access, the bucket itself would reject it.

---

🔐 RCPs: Security That Sits On the Resource

Unlike IAM or SCPs that check who is asking and what permissions they have…
RCPs go further.

They sit on the resource (S3 bucket, Secrets Manager, etc.) and say:

“Unless this policy approves it, the action won’t happen—no matter who you are.”

This is next-level control, especially in multi-account environments.

---

📦 Supported Services (as of now)

As of writing, RCPs support only a few AWS services:

• Amazon S3

• AWS KMS

• AWS STS

• AWS SQS

• AWS Secrets Manager

Arjun hopes more will come soon, like EC2 or Lambda.

---

⚠️ Things RCPs Don’t Do

Just like SCPs, RCPs have limitations:

• ❌ They don’t affect the management account (only member accounts)

• ❌ They don’t control service-linked roles (like roles AWS uses internally)

• ❌ They don’t apply to AWS-managed KMS keys

• ❌ They don’t grant any permission — IAM is still needed

Even root users in member accounts are restricted by RCPs.

---

✅ When to Use RCPs (AWS SAA Exam Tip!)

If you're preparing for the AWS SAA (Solutions Architect Associate) exam, RCPs are a security best practice for large orgs using multiple accounts.

You should use RCPs when:

• You want to prevent public access to buckets across the org

• You want to limit Secrets Manager secrets to certain actions only

• You want to block accidental cross-account sharing of resources

• You want guardrails that apply even to root users

---

🧪 Arjun's Testing Strategy

Before rolling it out to production, Arjun:

1. Tested RCPs on a sandbox account

2. Monitored for AccessDenied events in CloudTrail

3. Gradually applied them to dev and staging OUs

4. Finally applied to prod OU

This step-by-step rollout prevented outages and gave his team time to adjust.

---

🎯 Final Thoughts from Arjun

“SCPs protect people. RCPs protect resources.
Put them together, and you build a fortress.”

Thanks to RCPs, Arjun could now sleep better at night, knowing that even if someone messed up an IAM policy or attached a dangerous bucket policy—the resource itself would say no.

---

📘 TL;DR (Too Long; Didn't Read)

---

Follow me for more such content

• My YouTube Channel

• My Blogs

• AWS Community

• Medium

• LinkedIn

• Instagram

• Github

• Dev

• X