5 The Shared Responsibility Model · AWS Cloud Practitioner

This chapter opens Domain 2, Security and Compliance, which is 30 percent of the scored exam. In this chapter you will learn what AWS is responsible for (security of the cloud) and what you are responsible for (security in the cloud), how controls are classified as inherited, shared, or customer-specific, and how the dividing line moves as you go from Amazon EC2 to containers, managed databases, and serverless services. You will work through more than ten scenarios and learn the traps the exam sets. This chapter maps to Task Statement 2.1: “Understand the AWS shared responsibility model.”

5.1 Two parties, one secure system

When you rent an apartment, the landlord is responsible for the building: the foundation, the roof, the front door lock, the wiring inside the walls. You are responsible for your unit: locking your own door, deciding who gets a key, and not leaving the stove on. If a burglar walks in because you left your door open, that is not the landlord’s fault. If the roof collapses, it is not yours.

Security in AWS works the same way. AWS and the customer each own part of the job, and the system is secure only when both do their part. AWS calls this the shared responsibility model, and it is one of the most heavily tested topics on the Cloud Practitioner exam.

The model is often summarized in one line:

AWS is responsible for security of the cloud.

The customer is responsible for security in the cloud.

The AWS shared responsibility model

Customer

Aws

Security OF
the cloud
Software (foundation services)
Compute Storage Database Networking
Hardware and AWS global infrastructure
Regions Availability Zones Edge locations
Also: facilities, physical security, power and cooling, hypervisor

Figure 5.1: The shared responsibility model. AWS secures the global infrastructure and foundation services; the customer secures what they put in the cloud and how they configure it.

5.2 Security “of” the cloud: what AWS does

AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud. That includes: Physical security of data centers. Perimeter fencing, guards, video surveillance, badge and biometric access, and strict visitor logging. Customers cannot tour AWS data centers, and their locations are not publicly listed. Environmental controls. Power, backup generators, cooling, fire detection and suppression, and flood protection. Hardware. Servers, storage devices, and networking equipment, including replacing failed components and securely destroying decommissioned storage media.

The global infrastructure. Regions, Availability Zones, edge locations, and the private network that connects them.

The virtualization layer. The hypervisor (the AWS Nitro System on modern instances) that isolates one customer’s instances from another’s.

The software that runs managed services. For example, the operating system and database software behind Amazon RDS, or the servers that run AWS Lambda functions.

You cannot audit AWS data centers yourself, so how do you know AWS does these things? AWS is audited by independent third parties against standards such as ISO 27001, SOC 1, SOC 2, SOC 3, and PCI DSS. You can download these reports with AWS Artifact, which you will meet in the compliance chapter (Chapter 7).

5.3 Security “in” the cloud: what the customer does

The customer is responsible for everything they put into the cloud and every configuration choice they make. Depending on the service, that can include:

Customer data. Classifying it, deciding where it lives, and deciding who can see it.

Identity and access management. Creating IAM users, roles, and policies; enforcing least privilege; enabling multi-factor authentication (MFA); protecting the root user; rotating credentials. Guest operating systems. On Amazon EC2, the customer installs operating system patches and security updates. Applications. The code you write and the third-party software you install.

Network and firewall configuration. Security groups, network ACLs, route tables, and which resources have public access.

Encryption choices. Turning on encryption at rest and in transit, and managing keys (with AWS help through AWS KMS).

Client-side and server-side encryption, and network traffic protection (for example, using TLS).

Exam tip

A quick test for any responsibility question: Could the customer do it from the console, CLI, or API? If yes, it is almost always the customer’s job (configuring security groups, enabling encryption, writing IAM policies). If it requires physical access to a data center or touches the hardware or hypervisor, it is AWS’s job.

5.4 Inherited, shared, and customer-specific controls

AWS describes three types of IT controls under the model. This vocabulary appears on the exam.

Inherited controls are controls the customer fully inherits from AWS. The customer does nothing; AWS does it all. Examples: physical and environmental controls such as data center access, power, and cooling.

Shared controls apply to both the infrastructure layer and the customer layer, but in completely separate contexts. Each party implements the control for its own part:

Patch management. AWS patches and fixes flaws within the infrastructure; customers patch their guest operating systems and applications.

Configuration management. AWS maintains the configuration of its infrastructure devices; customers configure their own guest operating systems, databases, and applications.

Awareness and training. AWS trains AWS employees; customers train their own employees.

Customer-specific controls are solely the customer’s responsibility, based on the application they deploy. An example is service and communications protection or zone security, which may require the customer to route or zone data within specific security environments.

Common trap

“Shared” does not mean “AWS and the customer split the same task.” It means each party does the same kind of task for the layer it owns. AWS never patches your EC2 guest operating system, and you never patch the hypervisor.

5.5 The line moves: responsibility by service type

The model is not one fixed line. Where the line falls depends on the service. The more AWS manages, the less you manage. Figure 5.2 shows the general pattern.

The responsibility slider: who handles each layer?

Aws aws aws aws

Customer Shared (customer chooses, AWS operates) AWS

Figure 5.2: The responsibility slider. As you move from infrastructure services toward serverless, AWS takes on more of the stack, and the customer’s share shrinks to data, access, and code.

Amazon EC2 (infrastructure as a service)

EC2 gives you the most control and therefore the most responsibility. AWS secures the physical host, the hypervisor, and the network infrastructure. You are responsible for:

The guest operating system: patches, updates, hardening, and antivirus where needed Any application software and utilities you install

Security group and network ACL configuration
IAM roles attached to the instance and the credentials used to reach it
Encrypting EBS volumes and data in transit

Backups (for example, EBS snapshots) and high-availability design across Availability Zones Containers: Amazon ECS on EC2 vs. AWS Fargate

With Amazon ECS or Amazon EKS running on EC2 instances that you manage, you still patch those instances’ operating systems and container runtime (unless you use managed options that handle this for you). With AWS Fargate, AWS runs and patches the underlying hosts, operating system, and container runtime. You remain responsible for: Your container images, including vulnerabilities in the packages inside them

Your application code
Task IAM roles and permissions
Network configuration such as security groups and which tasks are reachable
Secrets handling and data encryption choices
Amazon RDS (managed database)

With Amazon RDS, AWS manages the database host, the operating system, and the database engine software, including installing patches during the maintenance window you choose. You are responsible for:

Database user accounts, passwords, and permissions inside the database
Security groups that control which clients can connect
Whether the database is publicly accessible

Turning on encryption at rest (best set when you create the database) and enforcing encrypted connections Choosing backup retention, Multi-AZ, and the maintenance window

The data and the schema

AWS Lambda (serverless compute)

With Lambda, AWS manages the servers, operating system, runtime environment patching for managed runtimes, scaling, and availability across Availability Zones. You are responsible for:

Your function code and its third-party libraries
The function’s execution role and who may invoke it
Environment variables and secrets
The data the function reads and writes
Amazon S3 (managed storage)

AWS operates the storage infrastructure, keeps it durable and available, and patches it. You are responsible for: Bucket policies, access control, and keeping S3 Block Public Access turned on unless you truly need public access Choosing encryption options (new objects are encrypted at rest by default with S3-managed keys, but key choices such as AWS KMS keys are yours)

Versioning, Object Lock, and lifecycle rules
Classifying the data and deciding what to store
Amazon DynamoDB and other fully managed services

For services such as DynamoDB, Amazon SQS, and Amazon SNS, AWS handles the entire infrastructure, operating system, and software. The customer manages data, IAM access, and settings such as encryption key choice, backups, and point-in-time recovery.

Who patches what?

* Some managed node options can patch nodes for you; otherwise the customer does.

† AWS applies engine patches in your maintenance window; you choose the window and upgrade settings. ‡ For managed runtimes. Custom runtimes and container-image functions are patched by you.

In every row, the customer still owns data, IAM permissions, and configuration settings.

Figure 5.3: Who patches what. Patching responsibility for common AWS services.

Exam tip

In every service, from EC2 to Lambda, the customer is always responsible for their data, IAM (who can access what), and the configuration settings they choose. These never move to AWS.

Good to know

Some AWS security services, such as Amazon GuardDuty, AWS Security Hub, and Amazon Inspector, help customers meet their responsibilities. Turning them on and acting on their findings is still the customer’s job. Using an AWS service does not transfer your responsibility to AWS.

5.6 Worked scenarios

Read each scenario, decide who is responsible, then check the explanation.

Scenario 1: A failed disk in a data center. A physical drive in an AWS storage array fails. Responsibility: AWS. Hardware replacement and secure destruction of failed media are part of security of the cloud.

Scenario 2: An unpatched Linux instance. A security bulletin is released for a Linux kernel flaw. A company runs 50 EC2 instances with that kernel. Responsibility: Customer. The guest operating system on EC2 belongs to the customer. AWS Systems Manager Patch Manager can automate the work, but the customer must set it up.

Scenario 3: A database engine bug on RDS. A security fix is released for the PostgreSQL engine used by an Amazon RDS instance. Responsibility: AWS applies the patch; the customer controls timing. AWS provides and installs engine patches during the customer’s maintenance window. The customer chooses the window and whether minor version upgrades are applied automatically.

Scenario 4: A public S3 bucket. An engineer turns off Block Public Access and grants public read on a bucket containing customer records. The data is discovered by outsiders. Responsibility: Customer. Bucket permissions are configuration. AWS provided the tools to block public access; the customer chose otherwise.

Scenario 5: Open SSH to the world. A security group allows inbound port 22 from 0.0.0.0/0. Responsibility: Customer. Security groups are customer-configured firewalls.

Scenario 6: Hypervisor isolation. A customer wants assurance that another tenant’s instance on the same physical host cannot read its memory. Responsibility: AWS. Isolation between instances is provided by the hypervisor, which AWS designs, maintains, and patches.

Scenario 7: A vulnerable library in a Lambda function. A popular open-source logging library bundled in a Lambda deployment package has a known vulnerability. Responsibility: Customer. Function code and its dependencies belong to the customer, even though AWS manages the runtime and servers.

Scenario 8: A Fargate host OS patch. A kernel flaw affects the operating system of hosts that run Fargate tasks. Responsibility: AWS. With Fargate, AWS manages the host operating system. The customer remains responsible for vulnerabilities inside the container image.

Scenario 9: Leaked access keys. A developer commits IAM access keys to a public code repository, and someone uses them to launch instances. Responsibility: Customer. Credential management is part of identity and access management, which is always the customer’s job. (AWS may detect and notify you about exposed keys, but protecting them is your responsibility.)

Scenario 10: Unencrypted EBS volumes. An auditor finds that EBS volumes holding sensitive data are not encrypted. Responsibility: Customer. AWS offers encryption (and an account setting to encrypt new volumes by default), but the customer decides whether to use it.

Scenario 11: Data center flood protection. A regulator asks how the company’s data is protected from floods and fire. Responsibility: AWS (inherited control). The customer can show AWS compliance reports from AWS Artifact as evidence. Scenario 12: Employee security training. A company must train its staff on phishing and safe handling of credentials. Responsibility: Customer (shared control). AWS trains its own employees; each customer trains its own. Scenario 13: Edge location network gear. A network device in an Amazon CloudFront edge location needs a firmware update. Responsibility: AWS. Edge locations are part of the global infrastructure.

Scenario 14: Availability design. A company runs its web application on a single EC2 instance in one Availability Zone, and the zone suffers a power event. Responsibility: AWS for the infrastructure; customer for the architecture. AWS maintains the facilities, but designing for high availability across multiple Availability Zones is the customer’s choice.

Real-world example

Real-world scenario: A retailer moves its online store from EC2 instances running a self-managed database to Amazon RDS and AWS Lambda. Its security team’s patching backlog shrinks, because AWS now patches the database host and engine and the servers behind Lambda. The team’s work does not disappear, however. It shifts toward reviewing IAM policies, scanning function dependencies, and making sure every database is encrypted and private. This is exactly what the slider in Figure 5.2 predicts.

5.7 Common traps

Common trap

No. Even in Lambda or DynamoDB, the customer owns the data, IAM permissions, and configuration settings.

Common trap

No. In RDS, AWS patches the operating system and database engine. The customer does not even have operating system access. Contrast with a database installed on EC2, where the customer patches both.

Common trap

AWS provides the encryption tools and protects the underlying key infrastructure. Deciding to encrypt, choosing keys, and controlling who can use the keys are the customer’s decisions.

Common trap

AWS secures the physical network and its devices. The customer configures security groups, network ACLs, routing, and VPC design.

Common trap

As explained above, each party does the work for its own layer.

Common trap

If an answer option mentions data center guards, hardware disposal, or the hypervisor, it is AWS’s responsibility. If the question asks what the customer must do, eliminate those options first.

Hands-on lab

Hands-on mini lab: see your side of the model in the console

1. Sign in to the AWS Management Console and open Amazon S3.
2. Choose Block Public Access settings for this account in the left pane and confirm all four settings are on. This is your responsibility.
3. Open Amazon EC2, choose Security Groups, and review the inbound rules of any group. Look for rules that allow 0.0.0.0/0; deciding whether they are acceptable is your responsibility.
4. In the EC2 console, open EC2 Dashboard, then Account attributes, then Data protection and security, and review the EBS encryption setting (always encrypt new volumes). Turning it on is your choice.
5. Open IAM and review the security recommendations on the dashboard, such as MFA for the root user.
6. Notice what you could not find anywhere: settings for data center access, hypervisor patching, or hardware replacement. Those belong to AWS.

Chapter 5 summary

AWS is responsible for security of the cloud: facilities, hardware, global infrastructure, the hypervisor, and the software that runs managed services.

The customer is responsible for security in the cloud: data, IAM, guest operating systems (where they have them), applications, network configuration, and encryption choices.

Inherited controls (physical and environmental) are fully AWS’s; shared controls (patch management, configuration management, awareness and training) are done by each party for its own layer; customer-specific controls (such as zone security) are the customer’s alone.

The more managed the service, the less the customer manages: EC2 > ECS on EC2 > Fargate and RDS > Lambda, S3, and DynamoDB.

On EC2, the customer patches the guest operating system; on RDS, AWS patches the operating system and engine during the customer’s maintenance window.

With Fargate and Lambda, AWS manages hosts and runtimes; the customer owns images, code, and dependencies. Data, IAM, and configuration are always the customer’s responsibility, regardless of service.

AWS compliance reports, available through AWS Artifact, provide evidence for controls the customer inherits.

Key terms

Term Definition

Shared responsibility model Division of security duties between AWS and the customer Security of the cloud AWS’s duty: infrastructure, facilities, hardware, hypervisor, managed service software

Security in the cloud Customer’s duty: data, access, configuration, guest OS,
applications
Inherited control Control fully provided by AWS, such as physical security
Shared control Control applied by each party to its own layer, such as patching
Customer-specific control Control solely the customer’s, such as zone security
Guest operating system The OS running insidean EC2 instance, managed by the
customer
Hypervisor Software layer that isolates instances on a physical host, managed
by AWS
Maintenance window Customer-chosen time when AWS applies patches to services
such as RDS
Practice questions

1. Under the AWS shared responsibility model, which of the following is AWS responsible for?

A. Configuring security groups B. Patching the guest operating system on EC2 instances
C. Physical security of data centers D. Encrypting customer data in Amazon S3

2. Which tasks are the customer’s responsibility when using Amazon EC2? (Choose two.)

A. Installing operating system security patches B. Replacing failed physical hard drives
C. Configuring security group rules D. Maintaining the hypervisor
E. Securing the facility’s power supply

3. A company uses Amazon RDS for MySQL. Who is responsible for applying patches to the database engine?

A. The customer, by connecting to the operating system B. AWS, during the maintenance window the customer chooses
C. An AWS Partner chosen by the customer D. Nobody; RDS engines are never patched

4. Which of the following is an inherited control that customers fully inherit from AWS?

A. Patch management B. Physical and environmental controls
C. Awareness and training D. Zone security

5. Which controls does AWS classify as shared controls? (Choose two.)

A. Configuration management B. Physical access to data centers
C. Patch management D. Service and communications protection
E. Hardware disposal

6. A company runs containers on AWS Fargate. Which is the company’s responsibility?

A. Patching the host operating system B. Scanning container images for vulnerable packages
C. Maintaining the physical servers D. Patching the container runtime on the hosts

7. A developer bundles an outdated open-source library with a vulnerability into an AWS Lambda function. Who is responsible for fixing it?

A. AWS, because Lambda is serverless B. AWS, because it manages the runtime
C. The customer, because it owns the function code and

dependencies

D. The library’s maintainers only

8. Which statement about the shared responsibility model is correct?

A. The customer’s responsibilities are the same for every

AWS service

B. The customer’s responsibilities decrease as services

become more managed

C. AWS is responsible for customer data in managed

services

D. AWS manages IAM policies for serverless services

9. A company stored sensitive files in an S3 bucket and configured the bucket to allow public reads. The files were accessed by unauthorized users. Who is responsible?

A. AWS, because S3 is a managed service B. The customer, because bucket access configuration is customer-managed
C. AWS and the customer equally D. The internet service provider

10. Which responsibility always remains with the customer regardless of the AWS service used?

A. Patching the operating system B. Managing the hypervisor
C. Managing access to their data through IAM D. Maintaining network hardware

11. A company wants to show auditors evidence that the data centers hosting its workloads meet ISO 27001 controls. What should it provide?

A. Photos of its own data center B. AWS compliance reports downloaded from AWS Artifact
C. Screenshots of its security groups D. A list of its IAM users

12. Which is AWS’s responsibility for Amazon DynamoDB?

A. Deciding which IAM users can read a table B. Choosing whether to enable point-in-time recovery
C. Patching the underlying servers and software D. Classifying the data stored in tables

13. A company runs a self-managed Microsoft SQL Server database on Amazon EC2. Who patches the SQL Server software?

A. AWS B. The customer
C. Microsoft, automatically D. AWS, during the maintenance window

14. Under the shared responsibility model, training employees on security best practices is:

A. Only AWS’s responsibility B. Only the customer’s responsibility
C. A shared control: AWS trains its employees, and

customers train theirs

D. An inherited control

15. Which of these is AWS’s responsibility for Amazon EC2?

A. Isolating instances from one another on the same

physical host

B. Choosing the AMI to launch
C. Encrypting EBS volumes D. Assigning IAM roles to instances

16. A company’s EC2-hosted website goes down because the company deployed it on a single instance in one Availability Zone, and that zone had an outage. Which statement is correct?

A. AWS is responsible for the downtime because it runs the

Availability Zone

B. The customer is responsible for designing the application

to span multiple Availability Zones

C. The customer is responsible for the zone’s power systems D. AWS must automatically move the instance to another zone

17. Which tasks are the customer’s responsibility for Amazon RDS? (Choose two.)

A. Patching the RDS host operating system B. Managing database user permissions
C. Controlling network access with security groups D. Replacing failed storage hardware
E. Installing the database engine

18. Which of the following moves the MOST security responsibility to AWS?

A. Running a database on Amazon EC2 B. Running containers on Amazon ECS with EC2 instances
C. Running code on AWS Lambda D. Running a database on a Dedicated Host

19. A security engineer says, “We enabled Amazon GuardDuty, so threat detection is now AWS’s responsibility.” Why is this incorrect?

A. GuardDuty is not an AWS service B. The customer is still responsible for enabling services and acting on findings
C. GuardDuty only works on premises D. Threat detection is an inherited control

20. Which statement correctly describes encryption under the shared responsibility model?

A. AWS decides which customer data to encrypt B. The customer chooses whether and how to encrypt data, using tools AWS provides
C. Encryption is not possible in managed services D. Encryption is an inherited control Answers and explanations

1. C. Physical security of facilities is security of the cloud. Security groups, guest OS patching, and data encryption choices are customer responsibilities.
2. A, C. On EC2 the customer patches the guest OS and configures security groups. Hardware, the hypervisor, and facility power belong to AWS.
3. B. RDS is managed: AWS patches the operating system and engine during the customer-chosen maintenance window. Customers have no operating system access to RDS hosts.
4. B. Physical and environmental controls are fully inherited from AWS. Patch management and training are shared; zone security is customer-specific.
5. A, C. Patch management and configuration management are shared controls (along with awareness and training). Physical access and hardware disposal are AWS’s; service and communications protection is customer-specific.
6. B. With Fargate, AWS manages hosts, the operating system, and the container runtime, but the customer owns what is inside its container images.
7. C. Customers own their function code and dependencies. AWS manages the servers and managed runtime, not the libraries you bundle.
8. B. The line moves with the service: more managed services shift more work to AWS. Data and IAM never move to AWS, so C and D are wrong, and A ignores the slider.
9. B. Bucket policies and public access settings are customer configuration. AWS provides Block Public Access, but the customer chose to grant public reads.
10. C. Data and access management are always the customer’s responsibility. OS patching depends on the service; the hypervisor and hardware are always AWS’s.
11. B. Customers inherit physical controls and use AWS’s third-party audit reports, downloadable from AWS Artifact, as evidence. The customer cannot audit AWS data centers directly.
12. C. AWS manages all infrastructure and software for DynamoDB. Access, backup settings, and data classification remain with the customer.
13. B. Software the customer installs on EC2 is the customer’s to patch. AWS patches SQL Server only when it is delivered as a managed service such as Amazon RDS.
14. C. Awareness and training is a shared control: each party trains its own people. It is not inherited because AWS cannot train your staff for you.
15. A. Instance isolation is provided by the hypervisor, which AWS manages. AMI choice, EBS encryption, and IAM roles are customer decisions.
16. B. AWS runs the infrastructure, but architecting for high availability across AZs is the customer’s choice. AWS does not automatically relocate a single instance.
17. B, C. Database users and security groups are the customer’s. AWS patches the host OS, installs the engine, and replaces hardware.
18. C. Lambda is serverless, so AWS manages servers, OS, runtime, and scaling. The other options leave the operating system and more with the customer.
19. B. Security services help customers meet their responsibilities but do not transfer them. The customer must enable GuardDuty and respond to its findings.
20. B. AWS provides encryption features and protects the underlying key infrastructure, but the customer decides what to encrypt and controls keys and access. Encryption is available in most managed services.