The AWS Shared Responsibility Model is the most reliably tested concept on the AWS Certified Cloud Practitioner (CLF-C02) exam. It sits at the heart of the Security and Compliance domain — about 30% of your score — and it shows up indirectly in the Cloud Concepts and Technology domains too. More importantly, getting it wrong in the real world is how organizations end up with exposed S3 buckets and leaked databases.
The model is simple to state and surprisingly easy to misapply under exam pressure. This guide breaks down exactly where the line sits, how it moves depending on the service you use, and the precise phrasing the CLF-C02 uses to test whether you really understand it — not just whether you’ve memorized a diagram.
The Core Idea: Security of vs Security in the Cloud
The entire model collapses into one sentence you should be able to recite:
AWS is responsible for security of the cloud. The customer is responsible for security in the cloud.
- Security of the cloud (AWS) — the infrastructure that runs all AWS services: the physical data centers, hardware, networking, and the virtualization layer.
- Security in the cloud (You) — everything you put on top: your data, your configurations, your access controls, your operating systems (where applicable).
A useful shorthand: AWS secures the things you cannot touch; you secure the things you control. You can’t walk into an AWS data center or patch their hypervisor — that’s AWS’s job. You can misconfigure an S3 bucket to be public — that’s yours.
| Responsibility | Owner | Examples |
|---|---|---|
| Physical data centers | AWS | Buildings, badge access, environmental controls |
| Hardware & global infrastructure | AWS | Servers, storage, networking gear, Regions, AZs |
| Virtualization / hypervisor | AWS | The layer that isolates customer instances |
| Managed service software | AWS | The RDS engine patching, S3 durability |
| Customer data | You | What you store, classify, and protect |
| Identity & access (IAM) | You | Users, roles, policies, MFA |
| OS, network & firewall config | You | EC2 patching, security groups |
| Client/server-side encryption | You | Choosing to encrypt, managing keys |
The Line Moves: Responsibility Shifts by Service Type
Here is the part that trips up most CLF-C02 candidates: the shared responsibility line is not fixed. Where AWS’s responsibility ends and yours begins depends on which type of service you use. The more managed the service, the more AWS handles — and the less you do.
Think of three broad categories:
- Infrastructure services (IaaS) — e.g. EC2. You manage the most.
- Container/managed services (PaaS) — e.g. RDS, Elastic Beanstalk. AWS manages more of the stack.
- Abstracted services (serverless/SaaS-like) — e.g. S3, Lambda, DynamoDB. AWS manages the most.
EC2 — you own the most
With Amazon EC2, you rent a virtual machine. AWS secures the host, hypervisor, and physical infrastructure — but the guest operating system is yours. That means:
- You patch the OS and any software you install.
- You configure the firewall (security groups, network ACLs).
- You manage IAM and any application-level access.
EC2 is the canonical “you do a lot” example. A CLF-C02 question like “Who is responsible for patching the guest operating system on an EC2 instance?” has a clear answer: the customer.
RDS — AWS takes over the database engine
Amazon RDS is a managed database. Now AWS handles things that were yours on EC2:
- AWS patches the database engine and underlying OS.
- AWS manages backups, failover, and the infrastructure.
- You still control the data, who can access it (IAM and database credentials), network exposure (security groups, public accessibility), and whether encryption is enabled.
So the line moved inward toward AWS: you no longer patch the OS, but you’re still on the hook for access and data. “Who patches the underlying operating system for an Amazon RDS instance?” → AWS. “Who controls which users can connect to the RDS database?” → the customer.
S3 and Lambda — AWS manages nearly everything except your data and access
With abstracted services, AWS operates the entire platform. For Amazon S3:
- AWS manages the infrastructure, durability, availability, and the storage software.
- You decide what data goes in, who can access it (bucket policies, IAM, Block Public Access), and whether it’s encrypted.
The infamous “public S3 bucket” breach is always a customer responsibility — AWS gives you the controls (and now blocks public access by default), but choosing to expose data is on you.
For AWS Lambda, AWS runs and patches the entire execution environment. You are responsible only for your function code, its IAM execution role, and the data it touches. You never patch an OS for Lambda — there isn’t one you manage.
What’s Always Yours, Regardless of Service
No matter how managed the service, a few responsibilities never shift to AWS. The CLF-C02 tests these heavily because they’re the constant in a moving model:
- Your data — classification, ownership, and content are always yours.
- Identity and Access Management — creating users/roles, applying least privilege, enabling MFA, rotating credentials.
- Choosing to encrypt — AWS provides encryption tools (KMS, server-side encryption), but deciding to use them and managing client-side keys is yours.
- Account-level configuration — root account protection, enabling MFA on root, setting up CloudTrail.
A reliable exam heuristic: if the question involves data, identity, or access configuration, the answer is almost always the customer. If it involves physical infrastructure, hardware, or the hypervisor, it’s AWS.
What’s Always AWS’s, Regardless of Service
Equally constant — AWS always owns:
- Physical security of data centers (the “of the cloud” foundation).
- Hardware and the global network — Regions, Availability Zones, edge locations.
- The virtualization layer / hypervisor that isolates customers from each other.
- Maintenance of managed service software they operate on your behalf.
You will never be asked to patch a hypervisor or secure a data center door — those are textbook AWS responsibilities.
A Visual Way to Remember It
Picture a stack from the ground up:
+-----------------------------+
| Customer DATA | <- always YOU
| Platform, apps, IAM | <- YOU
| OS, network, firewall | <- YOU on EC2, AWS on RDS/Lambda
+-----------------------------+
| Managed service software | <- AWS (more, the higher the abstraction)
| Hypervisor / virtualization| <- always AWS
| Hardware / global infra | <- always AWS
| Physical data centers | <- always AWS
+-----------------------------+The bottom is always AWS, the top is always you, and the middle slides depending on how managed the service is. Internalize that picture and you can place any responsibility correctly.
Shared Controls: The Subtle Middle
The CLF-C02 occasionally tests shared controls — areas where both AWS and the customer have a role, just at different layers:
- Patch management — AWS patches the infrastructure; you patch your guest OS and applications.
- Configuration management — AWS configures its infrastructure devices; you configure your own OS, databases, and applications.
- Awareness & training — AWS trains its staff; you train yours.
When a question describes patching or configuration of customer-managed components, lean toward the customer. When it describes the underlying infrastructure, lean toward AWS.
How the CLF-C02 Frames These Questions
The exam rarely asks “explain the model.” It asks you to assign a single responsibility in a concrete scenario. Common patterns:
- “Who is responsible for patching the guest OS on EC2?” → Customer.
- “Who is responsible for the physical security of data centers?” → AWS.
- “Who configures security groups?” → Customer.
- “Who manages encryption of data at rest decisions?” → Customer (AWS provides the tools).
- “Who patches the RDS database engine?” → AWS.
- “Who is responsible for IAM user permissions?” → Customer.
Answer each by asking two questions: Is this physical/infrastructure (AWS) or data/access/config (customer)? and How managed is the service (does the OS responsibility even belong to me)? Those two questions resolve the vast majority of shared-responsibility items.
For a fuller map of how this domain fits alongside the rest of the exam, the CLF-C02 domains breakdown shows how Security and Compliance weighs against Cloud Concepts, Technology, and Billing.
Why It Matters Beyond the Exam
The shared responsibility model isn’t exam trivia — it’s the reason cloud breaches happen. Almost every major cloud data exposure traces back to a customer-side misconfiguration: an open S3 bucket, an over-permissive IAM policy, an unencrypted database, a security group open to 0.0.0.0/0. AWS secured the cloud flawlessly; the customer didn’t secure what was in it.
Understanding the model is what turns a Cloud Practitioner from someone who uses AWS into someone who understands where the guardrails are and who installs them. That perspective is genuinely valuable on the job, which is exactly why the exam invests so much in it.
Practice Until the Line Is Automatic
The shared responsibility model is easy to understand and easy to misapply when a question is phrased to tempt you toward the wrong side. The fix is repetition: enough scenario-style questions that placing a responsibility on the correct side of the line becomes automatic, even under a ticking exam clock.
That’s where realistic mock exams earn their place. Sailor.sh’s AWS Cloud Practitioner (CLF-C02) Mock Exam Bundle mirrors the real exam’s domain weightings and scenario phrasing, so you practice the shared responsibility model exactly the way the CLF-C02 tests it. Full-length, timed practice reveals the subtle questions that catch you — the RDS-engine patch, the shared control, the encryption decision — while you still have time to lock in the pattern.
To structure the rest of your preparation, pair this with the CLF-C02 study plan and the broader AWS Cloud Practitioner exam guide for 2026.
Conclusion
The AWS Shared Responsibility Model comes down to one boundary, drawn in the right place: AWS secures the cloud, you secure what you put in it — and that boundary slides toward AWS as services become more managed. Memorize the always-AWS items (physical, hardware, hypervisor), the always-customer items (data, identity, access, encryption decisions), and the service-dependent middle (the OS), and you’ve covered the model end to end.
Get this concept solid and you’ve locked in the single highest-yield topic on the CLF-C02 — and you’ve built the security instinct that prevents the most common real-world cloud mistakes. Learn the line, practice placing controls on the right side of it, and the Security and Compliance domain becomes one of your strongest.
FAQ
What is the AWS Shared Responsibility Model in one sentence?
AWS is responsible for security of the cloud (the physical infrastructure, hardware, and virtualization layer), while the customer is responsible for security in the cloud (their data, identity and access management, OS configuration where applicable, and encryption choices).
Does the shared responsibility line ever change?
Yes — it shifts based on how managed the service is. With EC2 (IaaS) you manage the guest OS and more; with RDS AWS patches the database engine and OS; with S3 and Lambda AWS manages almost everything except your data, access controls, and (for Lambda) your function code.
Who is responsible for a publicly exposed S3 bucket?
The customer. AWS provides the access controls — bucket policies, IAM, and Block Public Access (on by default) — but the decision to expose data is a customer-side configuration, making it a customer responsibility.
Who patches the operating system on AWS?
It depends on the service. On EC2, the customer patches the guest OS. On managed services like RDS, AWS patches the underlying OS and database engine. On serverless services like Lambda, there’s no customer-managed OS at all — AWS handles it.
What responsibilities are always the customer’s, no matter the service?
Your data, identity and access management (users, roles, least privilege, MFA), decisions about encryption, and account-level configuration (like protecting the root account). These never shift to AWS.
How much of the CLF-C02 exam covers the shared responsibility model?
It’s central to the Security and Compliance domain, which is roughly 30% of the exam — the largest single domain. The model also surfaces in other domains, making it one of the highest-yield concepts to master. Practicing with the CLF-C02 Mock Exam Bundle is an effective way to drill it.