Chapter 60: AWS Shared Responsibility
AWS Shared Responsibility
This is not just a fancy diagram you memorize for the Cloud Practitioner exam. This is the actual legal & operational contract between you and AWS about who is responsible for what when it comes to security, compliance, and operations.
If you get this wrong, you can end up with:
- Surprise ₹50,000+ bill from a forgotten public S3 bucket
- Data breach headlines in the newspaper
- RBI / DPDP Act compliance rejection
- “Why did my database get hacked?” panic at 3 AM
So let’s do this properly — like I’m your favorite teacher who actually wants you to never make those mistakes.
1. The Core Idea — One Simple Sentence You Must Memorize
AWS is responsible for the security of the cloud. You (the customer) are responsible for the security in the cloud.
That’s it.
Everything else is just explaining what falls into “of the cloud” vs “in the cloud”.
2. The Classic Diagram — What AWS Controls vs What You Control
Imagine a horizontal line splitting the responsibility:
Above the line (AWS is fully responsible) → The physical infrastructure and global network → Hardware, data centers, power, cooling, physical security → Hypervisor (the software that runs EC2 instances) → The AWS-managed parts of services (e.g., the RDS engine itself, not your data inside it)
Below the line (YOU are fully responsible) → Everything you configure, manage, or put inside AWS → Your data classification & encryption → Your IAM users/roles/policies/permissions → Your VPC configuration (security groups, NACLs, flow logs) → OS patching & application updates (on EC2) → Network ACLs, firewall rules, WAF rules → How you expose APIs/endpoints → How you log & monitor activity → Backup & recovery strategy → Compliance controls (who can access what)
3. Real-life Examples — Side-by-Side Responsibility
Let’s take four very common services and see exactly who does what.
| Service / Component | AWS is responsible for… | You (customer) are responsible for… | Typical Hyderabad Mistake (2026) |
|---|---|---|---|
| Physical data center | Power, cooling, physical security, fire suppression | — | None — AWS handles this perfectly |
| EC2 instance | The physical server hardware & hypervisor | OS patching, application updates, security groups, IAM role attached to instance | Leaving SSH port 22 open from 0.0.0.0/0 |
| Amazon S3 bucket | The S3 service itself (durability, availability, encryption at rest if enabled) | Bucket policy, block public access setting, object-level encryption, who has IAM access | Accidentally making bucket public → data leak |
| Amazon RDS (PostgreSQL) | The RDS engine, automatic patching, Multi-AZ failover, backups | Database user/password, encryption, parameter groups, VPC security group, who can connect | Storing DB credentials in Lambda code |
| Amazon VPC | The VPC service itself | Subnet design, route tables, security groups, NACLs, VPC endpoints, NAT Gateway | Putting RDS in public subnet |
4. Real Hyderabad Startup Example — Shared Responsibility in Action
Your startup “TeluguBites” (restaurant discovery + food ordering app):
What AWS is responsible for:
- The physical data centers in ap-south-2 (Hyderabad Region)
- The hypervisor that runs your ECS Fargate tasks
- The durability of your Aurora PostgreSQL database (replicated across AZs)
- The encryption of EBS volumes if you enable it
- The global network backbone that connects Regions & Edge Locations
What YOU are responsible for:
- Choosing Multi-AZ for Aurora (so if one AZ fails, the standby takes over)
- Creating Security Groups that allow inbound 5432 only from your ECS tasks (not from the entire internet)
- Enabling encryption at rest on Aurora & EBS
- Using IAM roles for ECS tasks (not hard-coded access keys)
- Setting bucket policy on S3 so only CloudFront can read photos (not the public)
- Enabling CloudTrail & GuardDuty to detect if someone is trying to misuse your IAM credentials
- Configuring WAF on your ALB to block SQL injection attempts
What happens if you forget your part:
- Public S3 bucket → someone finds customer photos → data breach news
- RDS security group allows 5432 from 0.0.0.0/0 → hacker brute-forces password → database dumped
- No CloudTrail → you can’t tell who deleted your production DynamoDB table
- No GuardDuty → crypto-mining malware runs on your EC2 for weeks → ₹50,000+ surprise bill
What happens when you do your part correctly:
- Aurora Multi-AZ + proper security groups → app stays up even during rare AZ outage
- KMS-encrypted S3 + CloudFront → fast & secure photo delivery
- GuardDuty + Security Hub → you get alert at 2 AM: “Unauthorized IAM role assumption detected” → you revoke & rotate keys before damage
- Monthly security cost: ~₹3,000–10,000 (very cheap insurance)
5. Quick Hands-On – Feel the Shared Responsibility
- Create an S3 bucket → try to make it public → see the Block public access setting (your responsibility)
- Launch EC2 → attach IAM role → try to access S3 without role → fails (your responsibility to attach correct role)
- Create RDS → see Multi-AZ checkbox (your responsibility to enable for HA)
- Enable CloudTrail → see that AWS logs API calls, but you must configure S3 bucket to store them
Summary Table — AWS Shared Responsibility Cheat Sheet (2026 – India Focus)
| Area / Responsibility | AWS Handles This (Security of the cloud) | You Handle This (Security in the cloud) | Most Common Mistake in Hyderabad Startups |
|---|---|---|---|
| Physical data center security | Yes | No | None — AWS does this perfectly |
| Hypervisor / host OS | Yes | No | None |
| EC2 instance OS patching | No | Yes | Forgetting to patch → vulnerabilities |
| S3 bucket public access | No | Yes | Public bucket → data leak |
| RDS / Aurora encryption | Offers the feature | You must enable it | Leaving DB unencrypted |
| IAM permissions | Provides the service | You define who can do what | Overly permissive roles |
| VPC security groups & NACLs | Provides the service | You write the rules | Allowing 0.0.0.0/0 on database port |
| GuardDuty / Security Hub alerts | Runs the detection | You enable it & respond to alerts | Not enabling → blind to threats |
Teacher’s final note (real talk – Hyderabad 2026):
The Shared Responsibility Model is the single most important thing you learn in AWS security. Everything else (WAF, GuardDuty, KMS, Secrets Manager…) is just details that sit on top of this model.
The biggest breaches and compliance failures in India happen because people forget:
“AWS secures the building. I secure what I put inside the building.”
Follow that one sentence religiously, and you’ll avoid 80–90 % of the pain others experience.
Got it? This is the foundation lesson — everything else in AWS security builds on top of it.
Next?
- Step-by-step: Build a secure VPC + Security Groups + WAF + GuardDuty?
- Deep dive: IAM roles vs users vs Identity Center?
- Or how to use AWS Security Hub to get a single security score?
Tell me — next whiteboard ready! 🚀🔒
