AWS Shared Responsibility Model
AWS secures the cloud. You secure what you put in it. Almost every cloud breach you have read about lives on one side of that line.
AWS runs the platform. You run what you built on it. The dashed line is the whole model.
Nobody at AWS will call you to say your storage bucket is open to the internet. Nobody will patch the operating system inside your virtual machine. Those things sit on your side of a boundary that AWS defines clearly, publishes openly, and expects you to know.
That boundary is the Shared Responsibility Model. It is not a legal disclaimer bolted onto the terms of service — it is a working description of who does what, and it is the reason cloud security incidents so often turn out to be configuration problems rather than platform failures.
The one-sentence version
AWS is responsible for security of the cloud. You are responsible for security in the cloud.
AWS handles the parts you cannot touch: the buildings, the racks, the hardware, the network between them, and the software that turns all of it into an API you can call. You handle everything you can touch: your data, your identities, your configuration, your code.
That split exists because it matches who can actually do the work. AWS cannot know which of your files are confidential. You cannot walk into an Availability Zone and replace a failed disk. Each side owns what it can genuinely control.
What AWS owns
- Physical security. Data centres, access control, environmental systems, hardware disposal.
- Global infrastructure. Regions, Availability Zones, edge locations, and the network linking them.
- The virtualization layer. The hypervisor, the host operating systems, the isolation between one customer’s workload and another’s.
- The managed services themselves. When you use RDS, AWS patches the database engine and the operating system under it. When you use Lambda, AWS owns the runtime, the fleet, and the scaling.
- Compliance of the underlying platform. AWS maintains the certifications and audits for the infrastructure and publishes the evidence through AWS Artifact.
How to spot it: if the thing that failed is physical, is the hypervisor, or is software AWS operates on your behalf, it is AWS’s side of the line.
What you own
- Your data. What it is, how sensitive it is, how long you keep it, and who is allowed to see it. AWS treats your data as opaque by design.
- Identity and access. IAM users, roles, policies, key rotation, multi-factor authentication, and who is allowed to do what.
- Configuration. Bucket policies, Block Public Access, security groups, network ACLs, subnet layout, encryption settings.
- Guest operating systems and applications. For EC2, that means kernel patches, agents, runtime versions, and everything you install.
- Your code. Dependencies, secrets handling, input validation — the ordinary discipline of writing software, which the cloud does nothing to change.
- Resilience choices. AWS gives you multiple Availability Zones. Whether you use more than one is your decision.
How to spot it: if the fix is a setting, a policy, a patch inside your instance, or a change to your code, it is your side of the line.
The parts that are genuinely shared
A few areas belong to both sides, which is where most confusion lives.
- Encryption. AWS supplies KMS, key management, and encryption options on nearly every service. Whether encryption is switched on, and which key is used, is yours.
- Patch management. AWS patches what it operates. You patch what you operate. The dividing line moves depending on the service, which is exactly why people get it wrong.
- Configuration management. AWS maintains the configuration of the infrastructure. You maintain the configuration of everything you create on it.
- Compliance. AWS gives you a compliant platform and the audit evidence to prove it. Building a compliant system on that platform is your work — and your regulator will ask you, not AWS.
One thing is never shared: accountability. You can hand off the work of running infrastructure. You cannot hand off answering for your own data.
The line moves with the service you choose
This is the single most useful idea in the model. The boundary is not fixed — it slides depending on how much of the stack AWS is operating for you.
Run a plain EC2 instance and you have taken on an operating system, a patch cycle, firewall rules, and everything you install. Move the same database to RDS and AWS takes over the engine and the OS underneath it, while you keep the schema, the database users, the network rules, and the decision to encrypt. Move to Lambda and even the runtime and scaling go to AWS, leaving you with your function code and its IAM permissions. Store objects in S3 and AWS guarantees the durability while you decide who can read them.
Get Ankur Batham’s stories in your inbox
Join Medium for free to get updates from this writer.
Notice what never transfers, no matter how far right you move: your data, your permissions, your configuration. A fully serverless architecture is not a fully secured one.
How to spot it: ask what AWS is operating on your behalf for that specific service. Everything else in the picture is yours.
Who owns it when something breaks
Reading the model as a diagram is easy.
The Availability Zone case deserves a second look, because it is the one people argue about. AWS is responsible for the zone going down. You are responsible for having deployed into a single zone, given that AWS publishes the failure mode, sells you multiple zones, and documents how to spread across them. Both statements are true at once, and the second one is the one your users will feel.
The same logic applies to backups. AWS keeps its storage durable; it does not decide that your accidental DELETE was a mistake. Retention, recovery points, and testing restores are yours.
Know the boundaries
Where teams get burned
Assuming managed means safe. RDS being patched by AWS says nothing about whether your database is reachable from the open internet. Managed refers to operations, not to your configuration.
Assuming defaults are secure. Many defaults are sensible now — new S3 buckets block public access, for example — but a default is not a policy. Enforce the setting at the account or organization level so a future engineer cannot quietly undo it.
Forgetting the AMI. A machine image you launched eighteen months ago has eighteen months of unapplied patches. Nobody upstream is fixing that for you.
Treating compliance as inherited. You inherit AWS’s controls for the infrastructure. You do not inherit compliance for the system you built on top of it.
Losing the model in the org chart. “Security in the cloud” spans data, identity, configuration, code, and resilience — which usually means five teams. If nobody owns the boundary end to end, it will be discovered by an auditor or an attacker.
Five questions to ask about your own account this week
- Can any bucket in this account be read from the internet, and would you know within an hour if that changed?
- When was the AMI behind your oldest running instance last rebuilt?
- Who can create an IAM user with administrative permissions, and how many of them are people rather than pipelines?
- Which of your workloads would survive one Availability Zone disappearing right now?
- If you deleted a production table by accident this afternoon, what would you restore from, and when was that last tested?
Where to go next
AWS Artifact gives you the compliance reports for the infrastructure side, which auditors will ask for and which you cannot produce yourself.
The model is short enough to read in an afternoon. Applying it honestly to an account you already run takes longer, and is the part that matters.
Written from AWS’s published guidance on the Shared Responsibility Model. AWS updates service-level responsibilities over time, so check the current documentation for the services you use.
