AWS Shared Responsibility Model Explained

The shared responsibility model is AWS's framework for dividing security duties between AWS and its customers. It is not a vague principle — it is a specific, drawable line that shifts depending on which service you use, and it is the single most-tested concept in Domain 2 (Security and Compliance) of the AWS Cloud Practitioner exam. Get this concept solid and a meaningful share of Domain 2's questions become straightforward.

The mental model

Picture an apartment building. The landlord (AWS) is responsible for the building's foundation, structural walls, fire suppression systems, and the locks on the building's main entrance. You, the tenant, are responsible for locking your own apartment door, deciding who gets a key, and what you keep inside. Neither party can fully secure the building alone — security is genuinely shared, split along a specific boundary.

“Of” the cloud vs “in” the cloud

AWS uses two precise phrases, and the exam expects you to recognize both instantly:

• Security “of” the cloud — AWS's responsibility. Physical data centers, hardware, the global network, and the virtualization/hypervisor layer.
• Security “in” the cloud — your responsibility. How you configure services, manage access, protect your data, and (on some services) patch the guest operating system.

If a question stem uses either phrase, it is testing this model directly — do not overthink it as a trick question.

How the line shifts by service model

The exact boundary is not fixed — it moves depending on how much of the stack AWS manages for a given service. The more AWS manages, the less falls to you.

The pattern to internalize: IAM, network configuration, and data are always yours, on every service. What moves is patching and runtime management — the more "managed" or "serverless" a service is, the more of that AWS absorbs.

Example: EC2 (infrastructure-as-a-service)

You launch an EC2 instance. AWS guarantees the physical server, host hardware, and hypervisor are secure and available. From the guest operating system upward, it is entirely on you: applying OS security patches, configuring the security group (AWS's virtual firewall), managing SSH key access, and securing whatever application you install. This is the service where your responsibility is broadest, because EC2 gives you the most raw control.

Example: RDS (managed platform)

With RDS, AWS manages the underlying EC2 instance, the database engine installation, and OS-level patching on a schedule you configure but do not perform yourself. Your responsibility narrows to: database-level user accounts and permissions, network access rules (security groups, VPC placement), enabling encryption at rest, and the queries and schema you run. This is the classic exam contrast to EC2 — "who patches the OS" flips from you to AWS.

Example: Lambda (serverless)

Lambda pushes the line even further toward AWS. There is no server for you to patch at all — AWS manages the entire execution environment, runtime, and underlying infrastructure. Your responsibility shrinks to your function code itself, the IAM role/permissions your function executes with, and any data your function touches. Serverless does not mean "AWS handles security" — it means AWS handles infrastructure security, while your code and permissions are still entirely your job.

Example: S3 (storage)

S3 is where a huge share of real-world breaches actually happen, precisely because the shared responsibility line is often misunderstood. AWS secures the underlying storage infrastructure and durability. You are 100% responsible for bucket policies, public-access settings, and encryption configuration — a publicly-exposed S3 bucket full of sensitive data is a customer misconfiguration, not an AWS failure, because access control on S3 is unambiguously "in the cloud."

Where data encryption fits

Encryption is a shared responsibility in its own right. AWS provides the tools — KMS for key management, built-in encryption-at-rest options on S3, EBS, and RDS, and TLS for data in transit. But enabling those options, managing your own keys if you choose customer-managed keys, and encrypting sensitive data client-side before it ever reaches AWS (where required by your compliance needs) are all on you. AWS will not silently encrypt data you did not configure it to encrypt.

Compliance and shared responsibility

AWS maintains compliance certifications (SOC 1/2/3, PCI DSS, ISO 27001, and many industry-specific ones) for the infrastructure it controls, available on-demand through AWS Artifact. But your use of AWS being compliant with a given standard (HIPAA, PCI DSS, GDPR) depends on how you configure access, encryption, and data handling — AWS being certified does not automatically make your application compliant.

Common misconceptions

• “AWS is fully responsible for my security since I'm paying them.” False. Payment does not shift the "in the cloud" half of the model.
• “Serverless means I don't need to think about security.” False. Your function code and its IAM permissions remain entirely your responsibility.
• “A managed database means AWS secures my data.” Partially false. AWS secures the engine and infrastructure; your access control, queries, and data content are still yours.
• “The responsibility split is the same for every service.” False — this is the exact misconception this article exists to correct. It shifts based on how much AWS manages.

How this is tested on CLF-C02

Expect questions phrased as "which party is responsible for X" across different named services, and questions using the exact "of the cloud" / "in the cloud" language directly. A reliable heuristic: if the question describes patching, encryption enablement, IAM configuration, or data content, the answer is almost always you. If it describes physical facilities, hardware, or the virtualization layer, the answer is almost always AWS. For managed services specifically, watch for the OS-patching question — it is the most common trap, because candidates default to "you patch everything" out of EC2 habit even when the scenario describes RDS or Lambda.

For more shared-responsibility-adjacent trap patterns across the full exam, see the Cloud Practitioner cheat sheet. You can also drill this concept specifically outside the cert bank in CertSharp's Shared Responsibility Model micro quiz.

Frequently asked questions