AWS Shared Responsibility Model: What You Actually Need to Know 2026

This guide is for anyone preparing for AWS CLF-C02 or SAA-C03 in 2026 who keeps getting shared responsibility questions wrong and needs a clear mental model.

The Core Concept

AWS handles the security of the cloud. You handle security in the cloud. This sounds simple, but the boundary moves depending on which service you use. On EC2, you patch the OS. On RDS, AWS patches the OS but you manage the data and access controls. On S3, AWS manages everything except the bucket policies and encryption settings you choose.

AWS Responsibilities: Security OF the Cloud

AWS is responsible for protecting the infrastructure that runs all services:

• Data center physical security (guards, cameras, biometrics)
• Hardware (servers, storage, networking equipment)
• Software that powers the cloud (hypervisor, host OS)
• Virtualization layer and global network
• Availability and durability of managed services

Customer Responsibilities: Security IN the Cloud

You are responsible for what you put in the cloud and how you configure it:

• Customer data and intellectual property
• IAM users, roles, policies, and MFA
• Guest operating system patches (for EC2)
• Application security and code
• Network traffic protection (security groups, NACLs)
• Encryption settings and key management

How It Changes by Service Type

Security is only one piece of the puzzle. For the broader architecture principles that govern every AWS service, see our Well-Architected Framework guide. Need a quick pre-exam review? Our printable cheat sheet covers both topics.

Common Exam Traps

• Trap 1: "Who patches the OS on RDS?" Answer: AWS. Many people guess customer because EC2 requires customer patching.
• Trap 2: "Who is responsible for S3 data encryption?" Answer: The customer chooses whether to enable it. AWS provides the mechanism.
• Trap 3: "Who manages network ACLs?" Answer: The customer. AWS manages the underlying network, but you configure NACLs and security groups.
• Trap 4: "Who is responsible for physical security?" Answer: Always AWS. This never shifts to the customer.

How the Boundary Moves by Service Type

The boundary moves depending on the service model, and exam questions are built around that movement rather than around the model itself.

On a virtual machine, you are responsible for the guest operating system, its patches, its configuration and everything running on it. AWS is responsible for the hypervisor and the hardware underneath it.

On a managed database, the operating system is no longer yours. You are responsible for the data, the schema, access control and the network rules that decide who can reach it. AWS handles the engine, the patching and the replication.

On a serverless function, almost everything below your code is AWS's responsibility. What remains yours is the code itself, its permissions and its dependencies, which is why an over-permissive role on a function is still a customer-side failure.

The pattern is that as the service takes on more management, your responsibility shrinks but never disappears, because there is no service in the catalogue where the customer is responsible for nothing at all. There is no service where the customer is responsible for nothing.

The Three Traps That Cost Marks

Three traps recur often enough to be worth naming before you sit the exam.

The first is answering from the service name rather than the layer. A question about a data breach in a managed database is usually testing whether you know that the customer owns access control even though AWS owns the engine. Candidates who answer "AWS, because it is managed" lose the mark.

The second is confusing the two directions of the model. Security of the cloud is AWS's responsibility and covers the infrastructure that runs every service. Security in the cloud is yours and covers what you put there. The words sound interchangeable and they are not.

The third is assuming patching is always AWS's job. It is for managed services. It is not for anything you install on a virtual machine, and a scenario describing an unpatched application server is testing exactly that.

Frequently Asked Questions