The AWS Shared Responsibility Model

Security is a shared job

When you run a workload in your own data center, you secure everything: the building, the servers, the network, the operating system, the application, and the data. Move that workload to AWS and some of those duties become AWS's job, while others stay yours. The AWS Shared Responsibility Model is the framework that draws this line. It says, for any given setup, who secures what.

This is the single most important security idea on the exam, and the most useful one in real work. Almost every security question on the AWS Certified Cloud Practitioner exam comes back to it. Once you can say where AWS's job ends and yours begins, you can reason through scenarios instead of memorizing answers.

Security of the cloud versus security in the cloud

AWS describes the split with two short phrases.

Security of the cloud is AWS's responsibility. AWS protects the infrastructure that runs every AWS service: the hardware, the software, the networking, and the physical facilities. This reaches from the host operating system and the virtualization layer down to the physical security of the buildings. You never touch these layers, and you cannot secure them yourself.

Security in the cloud is your responsibility. You secure what you put on top of that infrastructure: your data, your applications, your operating system configuration (when the service exposes one), your network and firewall settings, and who is allowed to access your resources. The exact list depends on the service you use.

A simple way to hold the two phrases apart: AWS secures the cloud itself, and you secure your stuff inside it.

Why AWS shares the responsibility

The model is not a way for AWS to avoid work. It reflects a basic fact: each side can only secure the parts it can reach.

AWS can lock the data center doors, patch the hypervisor, and replace failed hardware, because AWS owns and runs all of it. You cannot. But AWS cannot decide who in your company should read a file, choose a password policy for your users, or classify which of your records are sensitive. Only you can. The model gives each task to the side that is actually able to do it.

Sharing the work this way has a clear benefit. AWS takes on the heavy, repetitive infrastructure security that every customer would otherwise have to build and run alone, which lowers your operational burden. You keep control over your data and access, which is where your specific risks live.

The model extends to IT controls

The same shared logic applies to IT controls, the formal checks that prove a system is secure and compliant. Some controls you inherit fully from AWS, such as physical and environmental controls. Some are shared, where AWS handles the infrastructure side and you handle your side. And some are entirely yours.

You do not need the full control catalog for the exam. The point to remember is that the shared model is not only about day-to-day security tasks. It also shapes how compliance responsibilities are divided, which is why AWS gives customers documentation to verify the controls AWS runs on their behalf.

The line moves with the service

One detail trips people up, so fix it early: the boundary between AWS and you is not in a fixed place. It slides depending on the service.

Run a virtual server with Amazon EC2 and you manage the operating system, patches, and firewall rules yourself. Use a managed service instead and AWS takes over more of that work. Pick a fully abstracted service like Amazon S3 and AWS runs almost everything beneath your data. The next two lessons map this out: first the detailed split of who owns what, then how that split shifts as you move from raw infrastructure to fully managed services.

Exam tips

• Security of the cloud is AWS's job: hardware, software, networking, and physical facilities.
• Security in the cloud is your job: your data, access (IAM), operating system config, and network settings.
• A memory hook: AWS secures the cloud, you secure what you put in it.
• The split is not fixed. Your share depends on the service you choose.
• Your data and who can access it are always your responsibility, on every service.