When you use a cloud service like Amazon Web Services (AWS), who is responsible if a hacker breaks in and steals your data? Is it your fault, or is it AWS's fault? This question matters because the AWS Certified Cloud Practitioner (CLF-C02) exam expects you to understand exactly where your responsibility ends and where AWS's begins, so you can design secure systems and avoid costly surprises.
Jump to a section
A rented apartment is a clear division of responsibilities between a landlord and a tenant. The landlord owns the building, the roof, the plumbing, the electrical wiring, and the foundational structure. The tenant brings in their own furniture, their personal belongings, and decides how to arrange the living room. The landlord is responsible for fixing a leaky pipe in the wall, but the tenant is responsible for not clogging the sink with grease. The landlord must ensure the fire alarm works and the building's main water valve is functional. The tenant must change the smoke alarm's battery if it beeps in their unit, and they must lock their own door when they leave. If a burglar breaks in because the tenant left the window open, that is the tenant's problem, not the landlord's. However, if the burglar breaks in because the building's main entrance lock is broken, that is the landlord's responsibility. This division is not about who is more important; it is about who can practically control each part. The tenant has total control over what happens inside their rented unit, but no control over the building's central heating system. The landlord controls the building's core infrastructure but cannot tell the tenant what colour sofa to buy. This separation mirrors the shared responsibility model in cloud computing, where the cloud provider is like the landlord and the customer is like the tenant. Each party manages what is within their direct control, and the security of the whole arrangement depends on both parties fulfilling their specific duties.
The shared responsibility model is the fundamental security framework for cloud computing. It defines who is responsible for what, dividing security obligations between the cloud provider (AWS) and the customer (you). Before cloud computing, companies owned every piece of their IT infrastructure. They bought the servers, installed the cables, locked the server room doors, applied security patches to the operating system, and managed their own data. This is called on-premises (on-prem) computing. The company had total control and total responsibility.
Cloud computing changed this by allowing companies to rent IT resources on demand. But this renting created a question: who handles security for the rented parts? AWS cannot possibly manage the security of every single application its customers build, because AWS does not know what those applications do. At the same time, customers cannot secure the physical data centre, because they cannot even enter the building. So AWS and its customers split the work. This is the shared responsibility model.
AWS is responsible for the security of the cloud. This means AWS protects the physical infrastructure: the data centres, the servers, the networking cables, the cooling systems, and the hypervisor (the software that runs virtual machines). AWS also handles security for the managed services it offers, like the database service RDS (Relational Database Service) or the object storage service S3 (Simple Storage Service). For those services, AWS manages the underlying operating system and platform patches.
You, the customer, are responsible for security in the cloud. This means you control everything you put on top of AWS's infrastructure. Your responsibilities include:
Managing your customer data: what you store, how you encrypt it, and who can access it
Configuring your security settings, like who can open which ports on your virtual servers (security groups and network ACLs)
Patching the operating system of your own virtual machines (unless you use a managed service where AWS handles patching)
Managing the identity and access management (IAM) policies that control user permissions
Protecting your account credentials (your root user password and access keys)
A common model to visualise this is the layer cake. AWS provides the base layers: physical security, network infrastructure, and the hypervisor. You provide the top layers: your application code, your data, your user management, and your encryption choices. If a vulnerability exists in your application code, that is your problem to fix. If a vulnerability exists in the hypervisor that AWS runs, that is AWS's problem to fix.
The model changes slightly depending on the type of cloud service you use. There are three main service models:
Infrastructure as a Service (IaaS): You manage the operating system, applications, and data. AWS manages the physical hardware, network, and hypervisor. Example: running your own virtual machine on Amazon EC2 (Elastic Compute Cloud).
Platform as a Service (PaaS): AWS manages the operating system and runtime environment. You manage only your application and data. Example: using AWS Elastic Beanstalk to deploy your code.
Software as a Service (SaaS): AWS (or a third-party vendor) manages everything from the hardware up to the application. You just use the software and manage your data. Example: using Amazon Chime for video conferencing.
The shared responsibility model exists to give customers flexibility. You can choose how much control you want to hand over to AWS. If you want complete control, you use IaaS and accept more responsibility. If you want to worry less about patching and maintenance, you use PaaS or SaaS, but you give up some control. The exam tests whether you know exactly which responsibilities fall to you in each scenario.
Understand the division boundary
The model draws a line at the hypervisor level. AWS manages everything below the hypervisor (physical hardware, networking, data centre). The customer manages everything above (guest OS, applications, data). This boundary is the foundation of all responsibility decisions.
Identify the service model
Determine whether you are using IaaS (e.g., EC2), PaaS (e.g., RDS), or SaaS (e.g., Chime). Each model shifts the boundary. In IaaS, you manage the OS. In PaaS, AWS manages the OS. In SaaS, AWS manages everything except your data.
Review the customer's control pane
The customer uses AWS Management Console, CLI, or SDK to configure resources. Anything you can configure (IAM, security groups, bucket policies, encryption settings) is your responsibility. If you fail to configure it securely, you are liable.
Check AWS-managed parts
For services like S3, DynamoDB, or Lambda, AWS handles the underlying infrastructure. You do not patch Lambda's runtime, but you do manage your function's code, IAM permissions, and trigger configurations. Always ask: 'Is this a physical component or an abstract service?'
Plan for incident response
When a security incident occurs, the first step is to determine whether the root cause is in AWS's domain (e.g., hypervisor bug) or the customer's domain (e.g., misconfigured security group). This determines who investigates and who bears the cost. AWS provides tools like CloudTrail and GuardDuty to help you monitor your side.
Consider a medium-sized e-commerce company called 'ShopFast' that is migrating its online store to AWS. The company has ten employees and sells handmade furniture. They want to host their website on AWS and store customer orders in a database. The IT manager, Priya, needs to understand the shared responsibility model to avoid a security breach that could expose customer credit card details.
Priya first sets up an AWS account. She creates a virtual machine using Amazon EC2 to run the web server. She is responsible for:
Choosing a secure password and rotating it regularly
Applying security patches to the operating system (e.g., Ubuntu) every month
Configuring the security group (a virtual firewall) to only allow traffic on port 443 (HTTPS) for web traffic and port 22 (SSH) for her own admin access
Installing and configuring the web server software (e.g., Apache or Nginx)
Writing secure code for the website that prevents SQL injection attacks
Meanwhile, AWS is responsible for:
Physical security of the data centre where the EC2 instance runs
Preventing network sniffing between instances on the same physical host
Keeping the hypervisor (the software that runs the virtual machine) patched
Providing redundant power and cooling
One day, Priya's colleague accidentally makes the S3 bucket containing customer order backups publicly readable. This is a customer responsibility because Priya did not configure the bucket policy correctly. AWS provides tools like S3 Block Public Access to prevent this, but Priya did not enable them. A security researcher finds the bucket and downloads 50,000 customer records. ShopFast is liable, not AWS, because AWS gave them the controls; ShopFast failed to use them.
Another scenario: a vulnerability is discovered in the Xen hypervisor (the software that powers older EC2 instances). AWS immediately patches the hypervisor across all its data centres. This is AWS's responsibility, and customers do not need to take any action. The instances continue running without the customer's involvement.
In a typical week, Priya:
Checks AWS IAM reports to see if any users have unused permissions
Reviews CloudTrail logs (a service that records API activity) to spot unusual access attempts
Tests a backup restore from an encrypted snapshot to ensure disaster recovery works
Updates the security group rules to block traffic from an IP range that generated a high number of failed login attempts
Escalates a ticket to AWS Support when she cannot figure out why an EC2 instance is unreachable (it turns out a network ACL was misconfigured — her responsibility)
This step-by-step reality shows that the shared responsibility model is not a theoretical concept. It dictates daily actions and determines who pays the cost when something goes wrong.
The CLF-C02 exam tests the shared responsibility model heavily. You can expect at least 3-5 questions on this topic. The exam wants to verify that you can correctly identify which party is responsible for a given security control in different scenarios. The questions are often scenario-based: 'A company uses Amazon S3 to store sensitive documents. An employee accidentally shares a bucket publicly. Who is responsible?' The answer is always the customer.
Key concepts the exam loves:
Security OF the cloud vs. security IN the cloud: 'Security OF the cloud' is always AWS's responsibility — physical security, hardware, networking, hypervisor. 'Security IN the cloud' is always the customer's responsibility — data, applications, IAM, OS patching.
The three service models and their shifting responsibilities: For IaaS (EC2, VPC), the customer manages more than for PaaS (RDS, Elastic Beanstalk). For SaaS (Amazon Chime), the customer manages almost nothing except their data and users.
Customer-controlled services: S3 (bucket policies, encryption), IAM (users, roles, policies), Security Groups, Network ACLs, VPC configuration, encryption keys (KMS). If it appears under the customer's control, the customer is responsible.
AWS-managed services: When AWS manages the underlying OS (e.g., RDS, DynamoDB, Lambda), AWS handles patching and runtime security. The customer still manages data access and IAM.
Common traps the exam sets:
Offering 'AWS is responsible for your data encryption at rest' as a correct answer. AWS provides the tools for encryption, but you must enable and manage the keys (unless you use a fully managed encryption service like SSE-S3 with default settings). The exam expects you to know that data encryption is ultimately your responsibility unless the question specifies a fully managed service.
Suggesting that AWS handles patching of your EC2 instance's operating system. AWS never patches the guest OS on your EC2 instance. That is always your job.
Implying the customer is responsible for physical security. AWS never gives you access to their data centres, so physical security is always AWS's job.
Confusing the customer's responsibility for their own credentials with AWS's responsibility for the service. For example, 'Who is responsible if a customer's root user password is weak?' The customer.
Definitions to memorise:
Hypervisor: The software layer that runs and manages virtual machines. AWS manages the hypervisor.
Security Group: A virtual firewall for an EC2 instance. The customer configures it.
Network ACL: A firewall for an entire VPC subnet. The customer configures it.
IAM policy: A document that defines permissions. The customer writes it.
Shared Responsibility Model: The division of security obligations between AWS and the customer.
Pattern for correct answers: If the question asks about something the customer can control in the AWS Management Console, the answer is usually 'customer'. If it asks about physical hardware, global network infrastructure, or the hypervisor, the answer is usually 'AWS'. If the question involves a managed service like RDS or Lambda, the answer often involves shared or customer responsibility for data and AWS responsibility for the underlying service.
AWS is responsible for the security OF the cloud (physical data centres, hardware, hypervisor, global network).
The customer is responsible for security IN the cloud (data, IAM, OS patching, application configuration).
For IaaS (e.g., EC2), the customer manages the operating system and above; for PaaS (e.g., RDS), AWS manages the OS and runtime.
Data encryption at rest and in transit is the customer's responsibility to configure, even if AWS provides the tools.
The shared responsibility model changes depending on the service type: IaaS gives the customer more control and more responsibility; SaaS gives the customer less control and less responsibility.
A customer's root user password is their own responsibility, including rotating it and enabling multi-factor authentication.
These come up on the exam all the time. Here's how to tell them apart.
Security OF the Cloud (AWS responsibility)
AWS manages physical data centre security, including guards and cameras
AWS manages the hypervisor that runs virtual machines
AWS manages global network infrastructure and redundant power
Security IN the Cloud (Customer responsibility)
Customer manages guest operating system patching on EC2 instances
Customer manages IAM user permissions and access keys
Customer manages application-level firewall rules (security groups)
IaaS (e.g., Amazon EC2)
Customer manages the OS: applies patches, configures firewall
Customer installs and maintains the application software
Customer manages database if running DB on EC2
PaaS (e.g., Amazon RDS)
AWS manages the OS and runtime: automatic patching for the database engine
AWS manages the application software for the database
Customer still manages data access, encryption, and network rules
Customer-managed encryption (SSE-C)
Customer provides and manages the encryption keys
AWS does not store the keys; customer must manage key rotation
Offers highest control for compliance requirements
AWS-managed encryption (SSE-S3)
AWS manages and rotates the keys automatically
Simpler to use; no key management burden for the customer
Customer still configures encryption setting; AWS does not encrypt by default
Mistake
AWS is responsible for everything because they own the servers.
Correct
AWS is responsible for the security of the cloud (physical infrastructure, hypervisor, global network), but the customer is responsible for security in the cloud (data, IAM, OS patching, application code).
Beginners think 'owned means responsible' and do not realise customers have full control over their own configurations and data.
Mistake
If I use a managed service like RDS, I do not have to worry about any security configuration.
Correct
Even with RDS, the customer is still responsible for managing database access (usernames, passwords), encrypting data at rest and in transit (if desired), and configuring security groups to restrict network access.
People assume 'managed' means 'fully managed' including security decisions, but AWS only manages the infrastructure, not the customer's access controls.
Mistake
The shared responsibility model is about splitting costs.
Correct
The shared responsibility model is about dividing security obligations, not costs. Costs are determined by pricing models, not responsibility boundaries.
Beginners confuse IT financial models (like 'shared cost' or 'shared savings') with security accountability, because the word 'shared' appears in both contexts.
Mistake
If a hacker attacks my application because of a vulnerability in the hypervisor, I am responsible for the breach.
Correct
If the vulnerability is in the hypervisor (which AWS manages), AWS is responsible. The customer is only responsible for vulnerabilities within their own application code, configuration, and data management.
It is natural for a non-IT person to assume all security breaches are the provider's fault, but the model clearly separates control boundaries.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes. AWS provides encryption options (SSE-S3, SSE-KMS, SSE-C), but you must choose and enable them. If you store data without encryption and a breach occurs, it is your responsibility.
No. AWS provides tools like S3 versioning, EBS snapshots, and AWS Backup, but you must configure them. AWS is not responsible for your data durability unless you set it up.
You are. You control the password and can enable multi-factor authentication. AWS provides the virtual machine, but you manage access to it.
The third-party vendor adds another layer. AWS's responsibilities remain the same (physical infra, hypervisor). The third-party may manage the OS or application. You are still responsible for your own data and IAM. Read the specific vendor's agreement.
You can view AWS compliance reports (SOC, ISO, PCI) but cannot physically inspect data centres. AWS manages physical security. You can audit your own configurations using AWS Config and Security Hub.
AWS is responsible for infrastructure reliability, but you are responsible for designing for failure (e.g., multi-AZ deployment, backups). If you did not enable cross-region replication, you may lose data even if it is an AWS fault.
You've just covered The Shared Responsibility Model — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?