AWS for DevOps — Shared Responsibility Model
Shared Responsibility Model
One of the most important concepts in AWS — and a favourite topic on certification exams — is the Shared Responsibility Model. It defines exactly what AWS is responsible for and what you are responsible for when it comes to security.
The Core Idea
AWS secures the cloud. You secure what you put in the cloud.
This means AWS handles the physical infrastructure — the buildings, servers, network hardware, and hypervisors. You handle everything you configure on top of that — your operating systems, applications, data, and access controls.
The Split
┌─────────────────────────────────────────────────┐
│ YOUR RESPONSIBILITY │
│ "Security IN the Cloud" │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Customer data │ │
│ │ Application configuration │ │
│ │ IAM (users, roles, policies) │ │
│ │ Operating system patches (EC2) │ │
│ │ Network configuration (security groups) │ │
│ │ Encryption settings │ │
│ │ Firewall rules │ │
│ └──────────────────────────────────────────┘ │
├─────────────────────────────────────────────────┤
│ AWS RESPONSIBILITY │
│ "Security OF the Cloud" │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ Physical data centres │ │
│ │ Hardware (servers, storage, networking) │ │
│ │ Hypervisor │ │
│ │ Network infrastructure │ │
│ │ Global infrastructure (Regions, AZs) │ │
│ │ Managed service infrastructure │ │
│ └──────────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘
It Changes by Service Type
The boundary shifts depending on which AWS service you use:
| Service Type | Example | AWS Manages | You Manage |
|---|---|---|---|
| IaaS | EC2 | Hardware, hypervisor | OS, patches, apps, data, security groups |
| Managed | RDS | Hardware, OS, patches, database engine | Schema, queries, data, backups config, access |
| Serverless | Lambda | Everything except your code | Function code, permissions, environment variables |
The more managed the service, the less you manage. This is why DevOps teams often prefer managed or serverless services — they shift operational burden to AWS.
Real-World Example
Imagine you run a web application on EC2:
| Task | Who? |
|---|---|
| The data centre has a lock on the door | AWS |
| The server hardware works | AWS |
| The hypervisor is patched | AWS |
| The OS is updated (Amazon Linux, Ubuntu) | You |
| SSH keys are rotated | You |
| Security groups only allow port 443 | You |
| The application code has no vulnerabilities | You |
| Customer data is encrypted | You |
Now compare that to Lambda:
| Task | Who? |
|---|---|
| Everything above (infra, OS, runtime) | AWS |
| Your function code is secure | You |
| IAM role has least privilege | You |
| Environment variables do not leak secrets | You |
Why This Matters for DevOps
As a DevOps engineer, the shared responsibility model tells you exactly what to automate and monitor:
- Patch management — Automate OS patches on EC2 with SSM Patch Manager
- IAM policies — Enforce least privilege with policy reviews
- Encryption — Enable encryption at rest for S3, EBS, RDS
- Network security — Lock down security groups and NACLs
- Audit — Enable CloudTrail to log every API call
Common Mistake
“We are on AWS, so AWS handles security.”
This is wrong. AWS secures the infrastructure. If you leave an S3 bucket public, that is your mistake — not AWS’s. If you use root account without MFA, that is your risk.
Quick Reference
| Concept | Description |
|---|---|
| AWS responsibility | Security OF the cloud (hardware, network, data centres) |
| Your responsibility | Security IN the cloud (data, config, IAM, encryption) |
| IaaS (EC2) | You manage most — OS, patches, security groups |
| Managed (RDS) | You manage data, access, backups config |
| Serverless (Lambda) | You manage code, IAM, environment only |
| Key takeaway | More managed = less you manage, but never zero |
Next → AWS Free Tier
