The AWS shared responsibility model explained

The split: of the cloud versus in the cloud

AWS’s side — security of the cloud — is everything required to run the services themselves. AWS secures the physical data centres (guards, access controls, surveillance), the hardware inside them, the network that connects them, and the software layers it operates: the hypervisor that hosts virtual machines, the managed-service infrastructure, the patching of everything below the line it hands to you. You cannot audit an AWS data centre or patch its hypervisor, so responsibility for those things could not sensibly be yours.

Your side — security in the cloud — is everything you put into the services and every choice you make about them. Your data and whether it is encrypted. Your IAM users, roles and permissions — who can do what in your account. Your network configuration: security group rules, what is exposed to the internet, how your resources reach each other. And, where you run your own servers, the patching of the guest operating system and the applications on it. The simplest test: if it is a setting you can change, it is yours to get right.

Concrete examples on each side

Placing real tasks on the correct side of the line makes the model tangible:

• AWS’s responsibility: physical security of data centres; the hardware and its maintenance; the virtualisation layer (hypervisor); the global network; patching the infrastructure underneath managed services such as databases and serverless platforms.
• Your responsibility: creating IAM users and granting permissions (and keeping them minimal); encrypting your data at rest and in transit; writing security group and firewall rules; deciding what is publicly accessible; patching the guest OS and applications on servers you run, such as EC2 instances.
• Genuinely shared ground: patch management (AWS patches the infrastructure, you patch your instances), configuration management (AWS configures its infrastructure, you configure your resources), and awareness — AWS trains its staff, you train yours.

The line moves — and this is the part people get wrong

The most examined subtlety is that the boundary is not fixed: it moves with the type of service you choose. With infrastructure services like EC2, you rent a virtual machine and take on everything above the hypervisor — the guest operating system and its patches, the runtime, your application, your data. Your responsibility list is at its longest. Choose a managed database instead, and AWS takes over the operating system and database engine patching; your side shrinks to your data, your access rules and your configuration choices. Go further, to serverless compute like Lambda or managed storage like S3, and there is no server or OS visible to you at all — AWS runs the entire platform, and your responsibility concentrates almost purely on code, data, permissions and configuration.

The direction of the shift is worth stating plainly: the more managed the service, the more AWS takes on — but your side never reaches zero. However serverless the stack, you still own your data, your IAM permissions and your configuration, and those are exactly the things that fail in practice. Candidates who assume “managed” means “AWS handles security” get scenario questions wrong; so do teams who assume it in production, with worse consequences.

How the customer side actually fails

The real-world failure patterns on the customer side are remarkably consistent. Over-permissive access is the most common: IAM users and roles granted far broader permissions than their job needs, so one leaked credential or compromised application can reach everything. Publicly exposed storage is the most notorious: storage buckets or databases left readable by the world through a configuration choice, discovered by automated scanners within hours. Unpatched instances come next — the guest OS on self-managed servers is the customer’s to update, and forgotten machines running old software are a standing invitation. Unencrypted data completes the set: encryption on AWS is largely a matter of turning it on and managing keys sensibly, which makes leaving it off a pure configuration failure.

Notice what all four have in common: none of them is a breach of AWS’s infrastructure. They are misuses of controls that were in the customer’s hands all along — which is exactly what the shared responsibility model predicts.

Why misunderstanding it causes breaches

When a cloud data exposure makes the news, the framing is often “data leaked from AWS”, and the instinctive reading is that the provider was breached. Almost always, the truth is a customer-side configuration failure — an exposed bucket, an over-broad permission — well inside the customer’s half of the model. The misunderstanding is not just a media problem; it is an operational one. A team that vaguely believes “the cloud is secure” or “AWS handles security” has, without noticing, assigned its own responsibilities to nobody. Nobody reviews the permissions; nobody checks what is public; nobody patches the instances — because everyone assumed that was someone else’s job.

This is why the model matters beyond the exam: it is an assignment of duties, and duties that are not clearly assigned are not done. The teams that stay out of the headlines are the ones who can say, for every layer of their stack, whether it is AWS’s job or theirs — and who audit their own half accordingly.

The most reliably examined concept in AWS certification

If one concept is guaranteed to appear on your AWS exam, it is this one. Cloud Practitioner (CLF-C02) has security and compliance as a scored domain, and shared-responsibility questions — “which of these is AWS’s responsibility?” — are a staple, often turning on the moving line between EC2 and managed services. The Solutions Architect – Associate (SAA-C03) embeds it in design scenarios: secure architectures depend on knowing which controls are yours to configure. The CloudOps Engineer – Associate (SOA-C03) tests it operationally, through patching, monitoring and access-management scenarios. The study advice is mercifully simple: internalise the of/in split, learn how the line moves across service types, and remember that your side never reaches zero. Get that trio solid and this becomes one of the most dependable sources of marks on any AWS paper.