The AWS Shared Responsibility Model Explained Simply
A beginner-friendly explanation of what AWS secures and what you are responsible for, using EC2, S3, and Lambda as examples.
Imagine you rent an apartment.
The landlord built the building. They maintain the walls, the roof, the wiring, and the main entrance. You never worry about the foundation.
Now imagine you leave your own front door wide open and someone walks in. Is that the landlord's fault?
No. And that is the whole idea behind the AWS Shared Responsibility Model.
AWS is the landlord. You are the tenant.
AWS secures the underlying cloud infrastructure: the data centers, the hardware, the networking, and the software that runs its services. You are responsible for securing what you configure and run in the cloud, with the exact responsibilities depending on the AWS service you use.
AWS puts it in one line: security of the cloud is AWS's job, security in the cloud is yours.
The catch: the size of your apartment changes
The more AWS manages for a service, the less you have to look after. Here is how it plays out:
- EC2 is like renting a bare unit. AWS secures the hardware and the virtualization layer, but you manage the operating system, patching, installed software, and security group rules.
- S3 is more like a storage locker. AWS runs the facility. You control who can access the locker, whether your data is publicly accessible, and how encryption is configured.
- Lambda is more like a serviced apartment. AWS manages the underlying infrastructure and managed runtime, while you remain responsible for your function code, dependencies, configuration, and permissions.
When the door gets left open
I did this myself on my first EC2 deployment. My connection wasn't working, so I opened the port to 0.0.0.0/0 to make it work. It worked. It also meant any IPv4 address on the internet could knock on that door.
AWS gave me a perfectly good lock. I propped it open. The same goes for a public S3 bucket or an IAM policy that allows far more than it needs. The service did exactly what it was configured to do. The configuration was the problem.
Three questions to ask for every service you use
- What does AWS manage here?
- What is left for me?
- Did I lock my own door?
Some things are shared. Patching is the classic case: AWS patches the infrastructure, but you patch the guest operating system and applications on your own EC2 instances.
The takeaway
AWS will keep the building secure. Your job is to look after your own door.
Official reference
Which AWS service did you find hardest to figure out the security side of?
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article