Domain 2 of 4 · Chapter 1 of 4

Shared Responsibility Model

Security OF the cloud vs security IN the cloud

Picture a horizontal line through a stack of EC2, RDS, S3, and Lambda: everything below it is AWS's job, everything above it is yours, and that single line answers nearly every "who is responsible" question this domain throws at you. The line is not fixed; it rises as a service becomes more managed (the next section moves it). AWS's half is "security OF the cloud": the global infrastructure that runs every service, the physical data centers, the hardware, the host operating system and virtualization layer, and the managed networking. The customer's half is "security IN the cloud": everything they put on top and configure (AWS Shared Responsibility Model[1]).

The line splits along one test: AWS owns the things you cannot touch (you will never walk into a data center or patch the hypervisor) and you own the things you turn on, upload, and configure. Below the line, AWS also owns the physical and environmental controls and the decommissioning of storage media so retired-hardware data stays unrecoverable.

Above the line, several duties stay permanently with the customer no matter the service: their own customer data, classifying that data, the IAM permissions for who can do what, the encryption options they enable, and the firewall / security group rules around their resources. The exam leans on this set because it never shifts to AWS, even for the most managed services. The two columns below name each half's duties side by side, with the dividing line running between them.

Security OF the cloud AWS responsibility Physical data centers Hardware Host OS + hypervisor Managed network Media decommissioning Security IN the cloud Customer responsibility Customer data Data classification IAM permissions Encryption options Firewall / security group Below the line: things you cannot touch Above the line: things you configure
The model's two halves side by side: AWS owns security OF the cloud, the customer owns security IN the cloud.

How the line shifts: EC2 to RDS to Lambda

This section moves the line from the model above: the most tested concept here is that the customer's share shrinks as a service becomes more managed, because the line rises and AWS absorbs more of the stack. AWS groups services into infrastructure, container/managed, and abstracted categories, and the boundary moves accordingly.

Amazon EC2 (IaaS / infrastructure): the line sits low, so the customer runs the most. AWS secures the hardware, hypervisor, and host. The customer owns the guest operating system (including its patching and updates), application software, security group / firewall configuration, and identity. EC2 "requires the customer to perform all of the necessary security configuration and management tasks" (AWS Shared Responsibility Model[1]). Patching the guest OS of an EC2 instance is a classic "customer responsibility" answer.

Amazon RDS (managed service): the line rises, so AWS now handles the operating system and the database engine patching, automated backups, and the underlying host. The customer no longer touches the OS, but still controls who can access the database (IAM and database credentials), the data itself, network access (security groups), and whether encryption is enabled (Amazon RDS Security[2]).

AWS Lambda (serverless): the line rises highest, so the customer offloads the most. AWS manages the servers, operating system, capacity, scaling, and runtime patching. The customer keeps only their function code, the function's IAM execution-role permissions, and their data (AWS Lambda, serverless compute[3]). There is no OS to patch at all.

The through-line: IaaS → managed → serverless hands progressively more operational security work to AWS, but the customer never gives up the data, IAM, and encryption duties from the model above.

Amazon EC2 (IaaS) Amazon RDS (managed) AWS Lambda (serverless) Guest OS + patching Applications Firewall (security group) IAM permissions Data + encryption Host, hypervisor, hardware Data + encryption IAM permissions Network access OS + engine patching Backups Host, hypervisor, hardware Function code IAM permissions Data Runtime patching OS, servers, scaling Host, hypervisor, hardware customer share widest narrower narrowest Boundary line rises → more managed → AWS owns more Above the line = customer (IN the cloud) · Below = AWS (OF the cloud) Data, IAM, and encryption stay with the customer in all three
The model's dividing line by service type, from the AWS Shared Responsibility Model: it rises (AWS owns more) EC2 → RDS → Lambda.

Shared controls: duties that belong to both sides

Some controls do not land cleanly on one side of the line: AWS calls them shared, meaning both sides act in the same area but at different layers. AWS calls out three (AWS Shared Responsibility Model[1]):

  • Patch management. AWS patches the infrastructure and the software of its managed services; the customer patches the guest OS and applications they run (for example, on EC2).
  • Configuration management. AWS maintains the configuration of its infrastructure devices; the customer configures their own guest operating systems, databases, and applications.
  • Awareness and training. AWS trains its own employees; the customer is responsible for training its own staff.

"Shared" means each side owns its own layer, not joint ownership, which is why the patch-management line moved between EC2 and RDS above; the diagram pairs each shared control's AWS layer with its customer layer. IAM sits on the customer side but is shared the same way: AWS provides it, the customer configures users, groups, roles, and least-privilege policies. AWS publishes its own compliance attestations (such as SOC and ISO reports) through AWS Artifact, so customers can evidence the AWS-controlled portion in their own audits (AWS Artifact[4]).

Patch management AWS layer Infrastructure + managed-service software Customer layer Guest OS + applications Configuration mgmt AWS layer Infrastructure devices Customer layer Guest OS, DBs, apps Awareness + training AWS layer Trains its own employees Customer layer Trains its own staff Shared = each side owns its own layer, not joint ownership
The three shared controls, each split into an AWS layer and a customer layer that own the same area at different depths.

Exam pattern recognition

This section applies the model to question stems. On CLF-C02, these questions usually give one task and ask "who is responsible: AWS, the customer, or shared?" Anchor on the abstraction level in the stem and recall where the line sits for it.

Always AWS (below the line, security OF the cloud): physical security of data centers, hardware, the hypervisor / virtualization layer, the host OS underneath managed services, decommissioning of storage media, and the managed global network. If the stem mentions a data center, a physical host, or the hypervisor, the answer is AWS.

Always the customer (above the line, security IN the cloud): the data they store, data classification, IAM users and permissions, choosing to encrypt data, security group / firewall rules, and, on EC2, patching the guest OS and installed applications. These are the always-customer duties from the first section; if the stem mentions "the data," "who can access," or "the OS on an EC2 instance," the answer is the customer.

Common distractor traps: (1) Claiming AWS patches the guest OS of an EC2 instance. It does not; that is the customer's job on EC2, though AWS does patch the OS for managed services like RDS (the line-shift from the second section). (2) Claiming the customer owns physical data-center security. Never; that is always AWS. (3) Claiming AWS encrypts your data automatically as a responsibility. The customer chooses and configures encryption; AWS provides the tools. (4) Treating "shared" controls like patch management as one party's job. Both contribute at different layers.

Who is responsible, by service abstraction level

Responsibility areaEC2 (IaaS)RDS (managed)Lambda (serverless)
Physical hardware & data centerAWSAWSAWS
Host hypervisor & virtualizationAWSAWSAWS
Guest OS patchingCustomerAWSAWS
Database / runtime patchingCustomerAWSAWS
Application code & logicCustomerCustomerCustomer
IAM permissions & accessCustomerCustomerCustomer
Data & client-side encryptionCustomerCustomerCustomer

Decision tree

Physical, hardware or hypervisor?AWS (OF the cloud)Is it patch / config /awareness management?Shared controlGuest OS / runtime on EC2,or data / IAM / encryption?Customer (IN the cloud)OS / engine patching on amanaged service (RDS, Lambda)?AWSCustomerYesNoYesNoData/IAMPatchingManagedEC2 OS
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

AWS owns security OF the cloud

Security "OF the cloud" is always AWS's: the global infrastructure that runs every AWS service. The hardware, the host operating system and hypervisor/virtualization layer, the managed network, and the physical data-center facilities. This boundary never moves regardless of which service you pick; the customer only ever owns what they layer on top.

Trap Treating the guest OS on an EC2 instance as part of AWS's "OF the cloud" scope. AWS owns the host and hypervisor, but the guest OS is the customer's.

7 questions test this
Customer owns security IN the cloud

Security "IN the cloud" is the customer's: everything configured and placed on top of AWS. The exact scope is determined by the services chosen: the more you manage yourself (e.g. EC2), the wider it gets; the more managed the service, the narrower. It always includes the customer's data, IAM permissions, and encryption choices.

2 questions test this
Physical and environmental security is always AWS, inherited by the customer

Physical data-center security, environmental controls, and the decommissioning of storage media are AWS "inherited controls" the customer fully inherits and never configures. When a drive reaches end of life AWS destroys it per NIST 800-88; the customer cannot touch or shift this layer.

Trap Assuming the customer can request or perform physical media destruction in an AWS data center, when media decommissioning is an inherited control AWS handles entirely.

6 questions test this
The customer always owns and classifies its data

Customer data is the one responsibility that never shifts to AWS regardless of service. The customer owns it, classifies it, and decides how it's protected. Even with fully abstracted services where AWS runs everything else, ownership and classification of the data stay with the customer.

Trap Assuming a fully managed or serverless service hands data protection to AWS. Managed services shrink the customer's scope but never absorb the data itself.

3 questions test this
Configuring IAM is always the customer's job

Identity and access management is always a customer responsibility: AWS supplies IAM, but the customer creates the users, groups, and roles and applies least-privilege permissions deciding who can access what. This holds across every service, including abstracted ones where IAM is most of what the customer configures.

Trap Expecting AWS to enforce least privilege by default. IAM starts deny-by-default, but scoping access to actual need is entirely the customer's to design.

5 questions test this
The customer decides and configures encryption

Encryption is a customer responsibility: AWS provides the tools (client-side and server-side options, KMS keys), but the customer chooses whether to encrypt and turns the options on. AWS never assumes liability for an unencrypted data store the customer left in the clear.

Trap Assuming AWS encrypts all customer data at rest automatically, when enabling encryption and selecting the keys is the customer's choice to make.

3 questions test this
The customer sets firewall and security-group rules

Network traffic protection at the customer layer is the customer's: configuring security groups and firewall rules to control what reaches the workload. On EC2 specifically, configuring the AWS-provided firewall (the security group) on each instance is explicitly the customer's responsibility.

Trap Treating the security group as something AWS manages because AWS provides it, when configuring its rules is the customer's responsibility.

14 questions test this
The customer's share shrinks as the service becomes more managed

Customer responsibility tracks the abstraction level: it is widest on infrastructure services (IaaS like EC2, where you own the guest OS), narrows on managed/container services (like RDS, where AWS takes the OS and engine), and is narrowest on abstracted services (like S3 and DynamoDB, where AWS runs the infrastructure and OS). Responsibility shifts toward AWS as you move up that spectrum.

Trap Assuming the customer's responsibility grows as a service becomes more managed, when it actually shrinks as more of the stack moves to AWS.

2 questions test this
On EC2 the customer patches the guest OS

Amazon EC2 is IaaS, so the customer manages the guest operating system (including updates and security patches) plus any installed application software and the security-group configuration. AWS only secures the underlying host, hypervisor, and hardware beneath the instance.

Trap Assuming AWS auto-patches an EC2 instance's guest OS the way it patches managed services. On IaaS that patching is the customer's job.

13 questions test this
RDS moves OS and engine patching plus backups to AWS

With managed Amazon RDS, AWS owns operating-system and database-engine patching, software installation, automated backups, scaling, and high availability; the customer is left with the data, access control (IAM), encryption choices, and query tuning. It's the canonical "managed service shrinks your share" example versus running your own database on EC2.

Trap Assuming the customer still patches the database engine and OS on RDS the way they would on a self-managed database, when RDS hands both to AWS.

11 questions test this
Lambda leaves the customer responsible only for code

With serverless AWS Lambda, the customer is responsible only for their function code. AWS manages the servers, operating-system maintenance, capacity provisioning, automatic scaling, and logging. The customer still owns the function's IAM permissions and the data it touches, but carries zero OS or server responsibility.

Trap Assuming serverless Lambda also relieves the customer of IAM and data responsibility, when those stay with the customer even though the OS and servers do not.

15 questions test this
Patch management is a shared control

Patch management is a named shared control: AWS patches and fixes flaws in the infrastructure (and in managed-service software), while the customer patches the guest OS and the applications it runs. The split follows the service: on EC2 the OS patching falls to the customer; on RDS or Lambda it shifts to AWS.

4 questions test this
Configuration management is a shared control

Configuration management is a named shared control: AWS maintains the configuration of its infrastructure devices, while the customer configures its own guest operating systems, databases, and applications. Both sides configure, but each only its own layer.

Trap Assuming AWS configures the customer's guest OS, databases, and applications because it configures its own infrastructure devices, when each party configures only its own layer.

1 question tests this
Awareness and training is a shared control

Awareness and training is a named shared control: AWS trains AWS employees, and the customer must train its own employees. Each party is accountable only for educating its own staff, not the other's.

For abstracted services the customer owns only data, IAM, and encryption

For abstracted services like Amazon S3 and Amazon DynamoDB, AWS operates the infrastructure layer, the operating system, and the platform; the customer accesses endpoints and is responsible for managing the data (including encryption options), classifying assets, and using IAM to apply the right permissions. It is the narrowest customer footprint of any service category.

Trap Assuming an abstracted service like S3 or DynamoDB leaves the customer with nothing to secure, when the customer still owns the data, its classification, encryption options, and IAM permissions.

4 questions test this

Also tested in

References

  1. https://aws.amazon.com/compliance/shared-responsibility-model/
  2. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.html
  3. https://aws.amazon.com/lambda/
  4. https://aws.amazon.com/artifact/