The AWS Shared Responsibility Model — and How to Remember It Forever

Jake — Wed, 16 Apr 2025 15:12:06 +0000

Introduction

The AWS Shared Responsibility Model shows who is in charge of what when it comes to security in the cloud.
It's easy to forget - but critical to understand. Especially for:

AWS certifications 🧠
Interviews 🤝
Actually securing your cloud ☁️🔐 So lets break it down with a real-life analogy and my trick to remember it forever.

What It Is

When you host something on AWS, security is a shared job:

AWS is responsible for the security of the cloud
You are responsible for the security in the cloud

My Analogy: An Apartment Building

Think of AWS as an apartment complex

Who	Responsibility
AWS (Landlord)	Locks the front gate, maintains security cameras, keeps the building safe
You (Tenant)	Lock your apartment door, don't leave the stove on, decide who gets your Wi-Fi password

Memory Trick

Saying out loud: "AWS secures the cloud. I secure what's IN the cloud"
Or if you're more of a visual learner:

AWS = hardware, networking, data center
You = data, access, app logic, configs

Mnemonic

OF the Cloud = Operations & Facilities
IN the Cloud = Instances & Networks

Real Examples

Here are some real examples to put into practice

AWS Service	AWS Responsibility	Your Responsibility
EC2	Physical Servers, Hypervisor	Patching OS, firewall settings
S3	Infrastructure, Uptime	Bucket Policies, Encryption Settings
RDS	DB engine updates	SQL Injection protection, User Permissions

Conclusion

You don't have to memorize every line of the AWS docs - just remember:

👉 AWS secures the cloud. You secure what’s in it.

Get that right, and you’re ahead of 80% of people trying to pass their cert or nail the “basic cloud security” interview question.

I’m sharing more bite-sized AWS concepts as I study for my Developer Associate cert — follow along and feel free to drop your own memory tricks in the comments!

AWS IAM: What It Is and Why Least Privilege Isn’t Optional

Jake — Tue, 15 Apr 2025 12:05:49 +0000

Think of AWS Identity and Access Management (IAM) as the security gatekeeper for your AWS account. It decides who can access what, and what they can do with it.

When IAM is set up well, it protects your infrastructure like a pro. When it’s not? You're one bad permission away from a serious security breach.

🔐 What Is IAM?

IAM lets you:

Create users, groups, and roles
Attach policies to define what actions they can perform
Control access to AWS services and resources (like S3 buckets, EC2 instances, etc.)

IAM isn’t just about functionality — it’s about security.

⚖️ The Principle of Least Privilege

“Only give permissions necessary to do the job — nothing more.”

This principle minimizes the potential damage from mistakes or malicious activity.

❌ Bad Example:

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

This allows a user to do anything in all S3 buckets — way too much power.

✅ Good Example:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::my-bucket-name/*"
}

Now the user can only read objects in a specific bucket. Safer, cleaner, better.

🛡 Why It Matters

In 2019, Capital One suffered a major breach due to an over-permissive IAM role.
Misconfigured IAM is one of the top causes of cloud security failures.
Least privilege isn’t just a best practice — it’s basic cloud hygiene.

👣 Takeaways

IAM controls access — treat it like a vault key.
Always ask: “Does this user/role need this permission?”
Use AWS managed policies to start, then customize as needed.

DEV Community: Jake