The AWS Shared Responsibility Model: What AWS Secures and What You Secure

The AWS shared responsibility model divides security work between Amazon Web Services and its customers. AWS is responsible for security of the cloud: the physical data centers, the hardware, the network, and the software that runs its managed services. You are responsible for security in the cloud: your data, your identities and permissions, your configurations, and whatever you install and run on the platform. Where exactly the line falls depends on how much of the stack the service manages for you.

What the model is and why it exists

When you run servers in your own data center, every layer of security belongs to you, from the door locks to the application code. Moving to AWS transfers part of that burden. AWS operates the physical facilities and the virtualization layer at a scale no single customer could match, and it carries the compliance certifications for that infrastructure. What AWS cannot do is decide who should access your data, write your bucket policies, or patch the operating system you chose to install. Those decisions stay with you, which is why the model is called shared rather than transferred.

The model matters on the CLF-C02 exam because it appears in Domain 1 (Cloud Concepts) and Domain 2 (Security and Compliance), and because it is the mental framework behind many scenario questions: given a task, whose job is it?

Security of the cloud: the AWS side

AWS owns and secures everything from the concrete floor up through the hypervisor and the managed-service software. Concretely, that includes:

• Physical security of Regions, Availability Zones, and edge locations: guards, badges, cameras, and controlled access to facilities.
• Hardware: compute servers, storage devices, and the lifecycle of that equipment, including secure decommissioning of failed drives.
• The global network: the fiber, routers, and switching that connect AWS facilities.
• Virtualization software: the hypervisor that isolates one customer’s EC2 (Elastic Compute Cloud) instances from another’s.
• Managed-service software: for services like Amazon RDS (Relational Database Service), DynamoDB, S3 (Simple Storage Service), and Lambda, AWS also patches and maintains the underlying operating systems, database engines, and runtimes.

You cannot audit an AWS data center yourself. Instead, AWS publishes third-party audit reports (SOC reports, ISO certifications, PCI DSS attestations) through AWS Artifact, which is how you inherit evidence for the layers AWS controls.

Security in the cloud: your side

The customer side of the model covers everything you put into AWS and every choice you make about it:

• Your data, including classifying it and deciding whether to encrypt it. Client-side encryption is always yours; even with server-side encryption, choosing to enable it is your call.
• Identity and access management: creating users and roles, enforcing least privilege, requiring multi-factor authentication (MFA), and rotating credentials. See IAM users, groups, roles, and policies for the mechanics.
• Operating system configuration on EC2: applying guest OS patches, hardening the image, and managing local accounts.
• Network configuration you control: security groups, network access control lists (network ACLs), subnet design, and firewall rules.
• Application code and any software you install, along with its updates.

A useful test: if you can configure it in the console or an API, securing it is your responsibility. AWS never sees a misconfigured security group as its problem to fix.

How the line moves by service type

The most tested nuance is that the boundary shifts with the service model. The more managed the service, the more AWS takes on.

Layer	EC2 (unmanaged compute)	RDS (managed database)	S3 / Lambda (abstracted)
Physical facilities and hardware	AWS	AWS	AWS
Hypervisor / platform software	AWS	AWS	AWS
Guest operating system patching	Customer	AWS	AWS
Database engine / runtime patching	Customer	AWS (customer sets the window)	AWS
Network controls (security groups)	Customer	Customer	Customer (bucket policies, access points)
Data, encryption choices, access policies	Customer	Customer	Customer

Notice what never moves: your data, your access policies, and your encryption decisions are customer responsibilities in every service, no matter how managed it is.

Shared controls

A few controls genuinely live on both sides, and the exam likes them because they resist a simple either/or answer:

• Patch management: AWS patches the infrastructure and managed-service software; you patch the guest OS and applications on EC2.
• Configuration management: AWS configures its infrastructure devices; you configure your operating systems, databases, and applications.
• Awareness and training: AWS trains its employees; you train yours.

When a question says a control is “shared”, it usually means one of these three.

How the CLF-C02 exam tests this

• “Whose responsibility is it?” with a specific task. The question names an action (patching the EC2 guest OS, configuring a security group, encrypting data client-side, maintaining physical security) and asks who is responsible. Map the task to the layer: anything you can configure is yours; anything physical or hypervisor-level is AWS.
• The same task across two services. A scenario contrasts patching a database on EC2 versus on RDS. On EC2 you patch the engine yourself; on RDS, AWS applies engine patches during your maintenance window. Expect the answer to hinge on the service model, not the task.
• A control that is always the customer’s. Watch for options like “AWS manages IAM user permissions” or “AWS classifies your data.” Data, identities, and access policies never transfer to AWS, so those options are wrong regardless of the service.
• Compliance evidence. A scenario asks how to obtain proof that AWS infrastructure meets an audit standard. The answer points to AWS Artifact, because you inherit AWS’s certifications rather than auditing the data center yourself; see AWS Artifact and compliance reports.

Quick reference

• AWS secures of the cloud: facilities, hardware, network, hypervisor, managed-service software.
• You secure in the cloud: data, IAM, guest OS on EC2, network rules, application code.
• The boundary moves with the service model; customer data and access policies never move.
• On EC2 you patch the guest OS; on RDS and other managed services, AWS patches the platform.
• Security groups, network ACLs, and bucket policies are always customer-configured.
• Shared controls: patch management, configuration management, awareness and training.
• AWS Artifact provides the audit reports covering the AWS side of the model.