AWS Shared Responsibility Model

What Is the AWS Shared Responsibility Model?

The AWS Shared Responsibility Model is the contractual and operational framework that divides security and compliance duties between Amazon Web Services (the provider) and you (the customer). AWS is responsible for the security of the cloud, while the customer is responsible for the security in the cloud. This single sentence is the most exam-tested idea in the entire CLF-C02 security domain, and knowing where the line falls for each AWS service is the backbone of Task Statement 2.1.

At a high level, the AWS Shared Responsibility Model tells you that AWS protects the global infrastructure that runs every AWS service — the data centers, the hardware, the hypervisors, the networking cables, the physical access badges. The customer, in turn, protects everything they place on top of that infrastructure — the data, the identities, the application code, the firewall rules, the encryption keys. The shared responsibility line is never fuzzy in the real world, but exam questions love to test the gray zones, especially when the service model shifts from IaaS to PaaS to SaaS.

The reason the AWS Shared Responsibility Model matters so much in CLF-C02 is that the Security and Compliance domain is weighted 30 percent — the single largest domain. Community surveys consistently flag "shared responsibility model" as the most-mentioned security concept in post-exam writeups, often with 400-plus mentions in a rolling twelve-month window. If you memorize nothing else before walking into the test, memorize the phrase "AWS secures the cloud, customer secures in the cloud" and the canonical examples for EC2, RDS, and Lambda.

Understanding the AWS Shared Responsibility Model is not just about passing a certification. It shapes how you design cloud architectures, how you respond to audit findings, how you write runbooks, and how you negotiate cloud contracts. Every serious AWS-based threat model begins with, "Is this my responsibility, AWS's, or shared?" — and that is the question this chapter will train you to answer on demand.

Plain-Language Explanation: AWS Shared Responsibility Model

Before diving into technical detail, let us use three different everyday analogies to lock the AWS Shared Responsibility Model into memory. Each analogy captures one facet of the shared responsibility pattern, and together they prevent the flat-memorization mistake many candidates make.

Analogy 1 — The Apartment Building (Realtor Pattern)

Think of AWS as the landlord of a massive secure apartment building. The landlord maintains the building's foundation, the locked lobby, the parking garage security cameras, the elevators, the fire sprinklers, the power grid, and the guards at the front gate. That is security of the cloud. You, the tenant, receive a key to your unit. Inside your unit, you decide who gets a key copy (IAM), what is stored in the safe (customer data), which window is locked (Security Groups), whether you set an alarm (CloudWatch), and what you put on your walls (application code). If someone walks into your unit and steals your laptop because you left the door unlocked, the landlord is not responsible — that is security in the cloud, and the shared responsibility model says it belongs to you. The landlord-tenant split makes the shared responsibility boundary intuitive: infrastructure below, customer choices above.

Analogy 2 — The Restaurant Kitchen (Kitchen Pattern)

Now picture the AWS Shared Responsibility Model as a restaurant kitchen that rents workspace to chefs. AWS owns the kitchen: the stoves, the refrigerators, the ventilation, the health inspection certificate, the licensed premises. That is security of the cloud. Each chef (customer) brings their own ingredients (data), chooses their own recipes (application logic), decides who can enter their station (IAM), tastes and approves each plate (configuration), and owns the reputation of their dish (business outcome). If the stove breaks, that is AWS's job. If the chef over-salts the soup, that is the chef's fault. Moving from EC2 (you cook from scratch) to RDS (AWS sous-chef does the prep) to Lambda (AWS hands you a pre-cooked component and you just plate it) is the same kitchen with more of the work handled by the kitchen staff — the shared responsibility model shifts with how much help you take.

Analogy 3 — The Insurance Policy (Insurance Pattern)

Finally, frame the AWS Shared Responsibility Model as a bundled insurance policy. AWS insures the physical layer — the building, the hardware, the hypervisor, the network fabric. Those perils (data-center fire, disk failure, hypervisor zero-day) are AWS's claim to cover. Your insurance premium (your AWS bill) does not, however, cover the content you stored on top. If you lose the policy number, leak your password, misconfigure a bucket to public, or fail to enable MFA on root, the shared responsibility model puts that loss squarely on you. AWS publishes an official compliance report (available through AWS Artifact) to prove their side of the coverage; you provide the audit evidence for your side. The insurance frame explains why the phrase is "shared" — neither party can deliver full security alone.

These three analogies — apartment building, restaurant kitchen, and insurance policy — each hit a different mental angle on the AWS Shared Responsibility Model. Mix them when explaining to teammates, and you will rarely be caught flat-footed on a scenario question.

Core Operating Principles — Security OF the Cloud vs Security IN the Cloud

The canonical framing of the AWS Shared Responsibility Model breaks the world into two verbatim phrases you must memorize: "Security of the cloud" and "Security in the cloud." The preposition is everything.

Security OF the Cloud (AWS's Job)

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

• Physical data centers — badge access, camera surveillance, 24/7 guards, multi-layer perimeter control.
• Hardware — servers, storage devices, networking equipment, and their disposal.
• Global network infrastructure — the private AWS backbone, Regions, Availability Zones, Edge Locations.
• Virtualization layer (hypervisor) — the Nitro System, host firmware, hypervisor patching.
• Foundational managed-service software — the RDS engine code, the Lambda execution environment, the S3 storage subsystem.

Security IN the Cloud (Customer's Job)

The customer is responsible for everything they put on top of AWS infrastructure. This includes:

• Customer data — you decide what to store, where, encrypted or not, retained how long.
• Platform, applications, identity and access management (IAM) — users, groups, roles, policies, MFA, root protection.
• Operating system patching (on IaaS services like EC2) — AWS does not patch your guest OS.
• Network and firewall configuration — Security Groups, Network ACLs, VPC routing, subnet design.
• Client-side data encryption and integrity checking — choose to encrypt at rest and in transit.
• Server-side encryption decisions — enable or disable, pick KMS-managed or customer-managed keys.

The AWS Shared Responsibility Model is fundamentally about abstraction. Every time AWS adds an abstraction (a hypervisor, a managed database, a serverless runtime), the security line moves up — AWS absorbs more, the customer owns less of the stack. This is the single most important exam principle.

AWS Responsibilities — What AWS Always Owns

Regardless of which AWS service you consume, AWS always owns a baseline set of responsibilities. In shared responsibility questions you will see phrases like "physical security of the data center" or "security of the network infrastructure" — those are always AWS.

Physical Data Centers

AWS maintains physical security with multi-factor authentication at facility entrances, biometric verification for employees entering data halls, and 24/7 surveillance. Visitors are escorted at all times. Data-bearing drives are physically destroyed or cryptographically erased before disposal using NIST 800-88 processes. This responsibility never shifts to the customer — it is baked into the AWS Shared Responsibility Model as pure "security of the cloud."

Hardware and Global Infrastructure

Servers, routers, storage arrays, cabling, cooling systems, and power distribution are entirely AWS-owned and maintained. When a disk fails in an EBS volume's underlying storage, AWS transparently replaces it — you do not file a ticket, and you do not see the hardware. Region, Availability Zone, and Edge Location availability, power, and cooling remain AWS's domain.

The Hypervisor and Host OS

Here is a key trap. AWS patches the hypervisor (the layer between bare metal and your EC2 instance). AWS does not patch the guest OS inside your EC2 instance. This boundary is one of the three most-tested gray zones in CLF-C02. The moment you launch an EC2 instance, the operating system running inside that virtual machine is the customer's to patch, harden, and monitor.

Customer Responsibilities — What You Always Own

No matter the service, a small set of responsibilities always belongs to the customer in the AWS Shared Responsibility Model.

Customer Data

You own your data end-to-end. AWS cannot access the content of your S3 objects, your DynamoDB items, or your RDS tables without your explicit permission (via IAM). Classification, retention, and deletion are yours. AWS will physically destroy the disks when they retire, but while data lives in your account, it is your data.

Identity and Access Management (IAM)

IAM is always a customer responsibility. AWS provides the IAM service, but you configure users, groups, roles, policies, MFA, password rotation, and root account protection. If someone leaves your company and you forget to revoke their access key, that is a customer-side failure under the shared responsibility model.

Application Code and Configuration

Any code you run on AWS — whether in EC2, Lambda, ECS, or EKS — is yours. Input validation, secrets handling, dependency patching for your application libraries, and SAST/DAST scanning all sit on the customer side of the AWS Shared Responsibility Model.

Data Encryption Choices

AWS offers encryption everywhere, but you decide whether to turn it on, which keys to use (AWS-managed vs customer-managed), and when to rotate them. S3 server-side encryption, EBS volume encryption, RDS encryption-at-rest, KMS key policies — all customer choices under the AWS Shared Responsibility Model.

Responsibility Boundary Shifts by Service Type — IaaS vs PaaS vs SaaS

The AWS Shared Responsibility Model is not a single line; it is a sliding scale. The more managed the service, the more AWS takes on, and the less the customer has to manage. CLF-C02 loves to test this shift, especially through scenario questions that change the service (EC2 → RDS → Lambda) and ask what changes about responsibility.

IaaS Example — Amazon EC2

EC2 is the classic Infrastructure-as-a-Service model. Under the AWS Shared Responsibility Model for EC2:

• AWS — physical data center, hardware, hypervisor, AWS-managed network fabric.
• Customer — guest operating system (patching, hardening), installed software, runtime, data, IAM, Security Groups, network ACLs, host firewall, encryption choices, monitoring agents.

EC2 pushes the most responsibility onto the customer. You own everything from the OS up. This is also why "EC2 OS patching" questions almost always have the customer as the correct answer.

PaaS Example — Amazon RDS

Amazon RDS is Platform-as-a-Service. The AWS Shared Responsibility Model for RDS moves the OS, database engine install, and DB patching to AWS.

• AWS — everything in IaaS plus the guest OS of the database host, database engine software, automated backups, patching windows for the DB engine, failover for Multi-AZ.
• Customer — database user accounts and permissions inside the engine, schema design, query performance, data, IAM for the RDS API, encryption at rest setting, Security Groups around the RDS endpoint, backup retention configuration.

SaaS Example — Amazon DynamoDB and AWS Lambda

For highly managed (sometimes called SaaS-like or serverless) services such as DynamoDB, Lambda, and S3, the AWS Shared Responsibility Model leans even further toward AWS.

• AWS — all infrastructure, OS, runtime, auto-scaling, patching of the service itself, availability, and the execution environment.
• Customer — application code (for Lambda), table design and access patterns (for DynamoDB), data, IAM, and encryption configuration.

For Lambda specifically, AWS owns and patches the runtime version you selected (for example, Python 3.12). But once AWS deprecates a runtime, you are responsible for migrating your code. The shared responsibility model does not let you ignore deprecation notices.

Side-by-Side Comparison — EC2 vs RDS vs Lambda Responsibility

Here is the canonical exam-ready table for the AWS Shared Responsibility Model across three service archetypes. Memorize the pattern, not every cell.

Notice the pattern: as you move from EC2 to RDS to Lambda, rows flip from Customer to AWS. This is the AWS Shared Responsibility Model in action. The exam rarely tests memorization of every row — it tests whether you grasp the pattern.

Shared Responsibilities — The Middle Ground

Some items in the AWS Shared Responsibility Model are genuinely shared. Both parties have roles, and getting this right is a CLF-C02 differentiator.

Patch Management (Shared Concept)

AWS patches the infrastructure it owns (hypervisor, managed service engines). The customer patches what they install on top (guest OS on EC2, application dependencies). The AWS Shared Responsibility Model frames this as "patch management — shared" because the concept applies to both sides, though each owns specific layers.

Configuration Management (Shared Concept)

AWS configures the underlying infrastructure for security best practices (default-deny hypervisor isolation). The customer configures their resources (bucket policies, SG rules, IAM policies). Each side has configurations; both must be correct for end-to-end security.

Awareness and Training (Shared Concept)

AWS trains its staff on security and publishes best-practice documentation. The customer trains its engineers and users. If a developer at your company leaks an access key on GitHub, that is a customer training failure. If an AWS engineer leaks internal data, that is AWS's training failure.

Encryption in Transit

TLS is a joint effort. AWS service endpoints offer TLS; the customer chooses to enforce HTTPS-only bucket policies, insists on TLS connections to RDS, configures VPN encryption, or enables Certificate Manager. Both sides cooperate.

Key Numbers and Must-Memorize Facts

CLF-C02 will not ask you to recite percentages, but it will ask you to know the canonical phrasing. Here are the memorization anchors.

• "Security of the cloud" = AWS responsibility (infrastructure).
• "Security in the cloud" = Customer responsibility (data, config, identity).
• Three items the customer always owns: data, IAM, network/encryption configuration.
• Three items AWS always owns: physical facilities, hardware, hypervisor.
• EC2 = customer patches guest OS. Period.
• RDS = AWS patches guest OS and DB engine. Customer patches their schema and app.
• Lambda = AWS patches runtime. Customer patches their function code and dependencies.
• S3 = AWS patches everything behind the API. Customer owns bucket policies, object ACLs, data classification.
• IAM is always customer. There is no service where AWS configures your IAM for you.
• Encryption key ownership depends on choice: AWS-owned keys (AWS manages), AWS-managed keys in KMS (AWS rotates, customer can audit), customer-managed keys in KMS (customer controls rotation and deletion).

Common Exam Traps — Gray Zones and Service-Type Shifts

The AWS Shared Responsibility Model generates some of CLF-C02's most persistent trap questions. Community data from the last twelve months shows "shared responsibility gray zones" as the single highest-frequency pain point in the Security and Compliance domain.

Trap 4 — S3 Object Permissions

S3 provides the bucket, but object-level ACLs, bucket policies, and Block Public Access settings are customer-owned. When a bucket is accidentally public, the AWS Shared Responsibility Model places 100 percent of the blame on the customer. AWS has even added Block Public Access as a default to help, but the choice to enable it is still customer.

Trap 5 — EC2 OS Patching

Exam writers love this one. A question asks, "Who patches the operating system on an EC2 instance?" The answer is always the customer, never AWS. AWS patches the hypervisor only. Use Systems Manager Patch Manager to automate it on your side if you want, but it remains customer responsibility under the AWS Shared Responsibility Model.

Trap 6 — Shared vs Customer vs AWS Wording

Some questions ask whether a task is "AWS-only," "customer-only," or "shared." For patch management as a concept, the answer is "shared." For patching the hypervisor, it is AWS. For patching the guest OS on EC2, it is customer. Read the question carefully to see whether it asks about the concept or the specific layer.

Shared Responsibility Model vs AWS Well-Architected Security Pillar

Both sit in the AWS security universe, and both appear in CLF-C02, but they answer different questions. The AWS Shared Responsibility Model says who is responsible for each security layer. The Well-Architected Security Pillar says how to do your side well.

AWS Shared Responsibility Model

• Purpose — a boundary contract.
• Output — a division of labor ("AWS does X, I do Y").
• Use — audit scoping, compliance evidence collection, incident blame analysis.

Well-Architected Security Pillar

• Purpose — best-practice framework for the customer side.
• Output — design principles (implement strong identity foundations, enable traceability, apply security at all layers, automate, protect data in transit and at rest, keep people away from data, prepare for events).
• Use — architecture reviews, security posture improvement, design guidance.

An exam question may juxtapose the two. If a scenario asks, "What framework defines who is responsible for patching the hypervisor?" — answer: AWS Shared Responsibility Model. If a scenario asks, "What principle recommends automating security best practices?" — answer: Security Pillar. The two are complementary but not interchangeable.

Practical Application — Real-World Decision Flow

Putting the AWS Shared Responsibility Model into action looks like this.

Step 1 — Identify Service Type

Is the workload running on EC2 (IaaS), RDS/ECS-on-EC2 (PaaS-ish), or Lambda/DynamoDB/S3 (managed/serverless)? This fixes the baseline responsibility split.

Step 2 — Overlay the Always-Customer Items

Data, IAM, and network controls are yours. Confirm policies exist.

Step 3 — Identify Shared Items

Encryption in transit and patch management as a concept. Define who does what at which layer.

Step 4 — Verify AWS's Side Via AWS Artifact

AWS Artifact hosts SOC 2 reports, ISO 27001 certificates, PCI-DSS Attestations of Compliance, and HIPAA BAAs. These documents are how AWS demonstrates they meet their side of the AWS Shared Responsibility Model. Auditors will ask for them.

Step 5 — Build Customer Evidence

You supply logs (CloudTrail for API audit, CloudWatch Logs for application), configuration snapshots (AWS Config), and IAM access reviews. This is your side of the evidence under the shared responsibility model.

Shared Responsibility in Compliance Frameworks

HIPAA, PCI-DSS, GDPR, SOC 2, ISO 27001, FedRAMP — every compliance regime AWS supports is scoped through the AWS Shared Responsibility Model. AWS provides compliance for the infrastructure scope (security OF the cloud); you inherit that and layer your controls on top (security IN the cloud).

For HIPAA, AWS will sign a Business Associate Agreement (BAA) covering HIPAA-eligible services. Everything inside your accounts that processes PHI is yours to manage. For PCI-DSS, AWS is certified as a Level 1 Service Provider; you must still configure your cardholder data environment within that scope. The AWS Shared Responsibility Model draws the boundary of what AWS certifies and what you must certify yourself.

Frequently Asked Questions — AWS Shared Responsibility Model

Q1: What is the single best one-sentence summary of the AWS Shared Responsibility Model?

A: AWS is responsible for security of the cloud (infrastructure), and the customer is responsible for security in the cloud (data, identity, configuration, and application). This exact phrasing is how AWS describes the shared responsibility model in every official document, and it is the phrasing CLF-C02 expects you to recognize.

Q2: Does AWS patch my EC2 operating system?

A: No. AWS patches the hypervisor and the host infrastructure, but the guest operating system on an EC2 instance is always the customer's responsibility under the AWS Shared Responsibility Model. Use AWS Systems Manager Patch Manager to automate OS patching — the automation can live in AWS, but the responsibility remains yours.

Q3: How does the AWS Shared Responsibility Model change for managed services like RDS or Lambda?

A: The boundary shifts upward. For RDS, AWS takes on the guest OS and database engine patching; the customer only manages data, schema, users, and IAM. For Lambda, AWS manages the runtime and execution environment; the customer only manages the function code and configuration. The more managed the service, the less the customer owns — but the customer never gives up responsibility for data, IAM, and encryption choices.

Q4: Who is responsible for IAM configuration in the AWS Shared Responsibility Model?

A: The customer, every time, for every service. AWS provides the IAM service itself (that is AWS's infrastructure responsibility), but the configuration — users, roles, groups, policies, MFA, root protection — is always customer responsibility. A leaked access key or an over-permissive policy is a customer-side failure.

Q5: Where can I find AWS's proof that they meet their side of the AWS Shared Responsibility Model?

A: AWS Artifact is the official self-service portal for AWS compliance reports and agreements. It hosts SOC reports, ISO certifications, PCI-DSS Attestation of Compliance, HIPAA BAAs, and many more. Customers use these to satisfy auditors that AWS has fulfilled the "security of the cloud" portion of the AWS Shared Responsibility Model.

Q6: If my S3 bucket is made public by accident, is that AWS's fault or mine?

A: Yours. Under the AWS Shared Responsibility Model, bucket policies and Block Public Access settings are customer-owned configuration. AWS provides secure defaults (Block Public Access is on by default for new buckets since April 2023), but the ultimate configuration choice — and the audit trail — sits with the customer. AWS did not leak your data; your configuration did.

Q7: Is encryption in transit AWS's responsibility or the customer's?

A: It is shared. AWS offers TLS on service endpoints and encrypts traffic between its internal services. The customer decides whether to enforce HTTPS-only access, whether to require TLS on RDS connections, whether to encrypt VPN tunnels, and whether to manage custom certificates via AWS Certificate Manager. Both parties must do their part for true end-to-end encryption in transit under the AWS Shared Responsibility Model.

Further Reading and Official Sources

• AWS Shared Responsibility Model — https://aws.amazon.com/compliance/shared-responsibility-model/ — the authoritative landing page.
• AWS Overview Whitepaper — Security and Compliance — https://docs.aws.amazon.com/whitepapers/latest/aws-overview/security-and-compliance.html — deep dive with examples.
• AWS Certified Cloud Practitioner Exam Guide (CLF-C02) — https://d1.awsstatic.com/training-and-certification/docs-cloud-practitioner/AWS-Certified-Cloud-Practitioner_Exam-Guide.pdf — Task Statement 2.1 detail.
• AWS Artifact — https://aws.amazon.com/artifact/ — compliance documentation hub.
• AWS Well-Architected Security Pillar — https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html — companion framework for how to do your side well.

Summary — AWS Shared Responsibility Model in One Page

The AWS Shared Responsibility Model is the answer to "who secures what" in every AWS conversation. AWS secures the cloud: data centers, hardware, hypervisor, managed service engines. The customer secures in the cloud: data, IAM, application configuration, network rules, encryption choices. The line shifts with the service type — IaaS EC2 pushes the most onto the customer, managed services like RDS take the OS and engine back to AWS, serverless services like Lambda and managed services like DynamoDB take even more. Three things always belong to the customer: data, IAM, and encryption configuration. Three things always belong to AWS: physical facilities, hardware, hypervisor. Memorize those anchors, understand the shift, and the AWS Shared Responsibility Model chapter of CLF-C02 is a guaranteed point-earner.