Security · Guide ·
AWS Shared Responsibility Model explained for busy leaders
Who secures what on AWS — in plain language for CTOs, IT directors, and audit conversations.
The shared responsibility model is on every AWS slide — and still misunderstood in incident postmortems. AWS secures the cloud. You secure what you put in the cloud.
AWS typically owns
- Physical data centers, hardware, hypervisor
- Managed service control plane security (e.g. S3 service itself)
- Global infrastructure availability and patching of the underlying platform
You typically own
- Data — classification, encryption choices, retention
- Identity — IAM, MFA, access keys, permission boundaries
- Network configuration — security groups, NACLs, routing, public exposure
- Guest OS and apps on EC2 — patching, hardening, code vulnerabilities
- Configuration of managed services — S3 bucket policies, RDS settings, Lambda env vars
The gray zone (where teams get burned)
Managed services shift the line. With RDS, AWS patches the engine; you still configure backups, parameter groups, and who can connect. With SaaS on EC2, you own almost everything above the hypervisor.
When someone says “AWS is SOC 2 compliant,” that does not automatically make your account compliant.
Three questions for your next staff meeting
- Do we have a written list of our controls vs. AWS’s for our top five workloads?
- Who is accountable for IAM reviews and public exposure monthly?
- When we adopt a new AWS service, do we run it through the same security checklist?
For tactical fixes, read 7 security mistakes we see every week. For migration-specific controls, start with the pre-migration checklist.