AWS Shared Responsibility Model: What AWS and Customers Secure

When an AWS security question asks, “Who is responsible?”, the correct answer usually depends on two things: what layer is being secured and which AWS service is being used.

This is Part 6 of the AWS Cloud Practitioner Study Notes series. The previous part explained the benefits of AWS Global Infrastructure; this note explains how security responsibilities are divided across that infrastructure and the workload you run on it.

The sentence to remember

The AWS Shared Responsibility Model divides security into two areas:

• AWS is responsible for security of the cloud.
• The customer is responsible for security in the cloud.

Security of the cloud means protecting the infrastructure that runs AWS services: facilities, hardware, networking, and the foundational software and virtualisation layers. Security in the cloud means protecting and configuring your workload, data, identities, applications, and service resources.

This is a shared model, not a hand-off of all security work to AWS. AWS secures the platform, while the customer secures what they deploy and configure on that platform. The exact boundary changes with the service.

What AWS manages: security of the cloud

AWS protects the underlying infrastructure used to operate AWS services. This includes responsibilities such as:

• Physical data centres and physical security
• Power, cooling, and environmental controls
• Physical servers, storage hardware, and networking equipment
• AWS Regions and Availability Zone infrastructure
• The host operating system and virtualisation layer where applicable
• Infrastructure-level replacement, maintenance, and protection

For example, if a physical server loses a component, a data-centre cooling system fails, or AWS networking hardware requires replacement, the underlying repair is AWS’s responsibility. You do not access or repair those physical systems.

That does not mean AWS is responsible for every security outcome in your account. AWS can secure the infrastructure while a customer-created IAM policy, public bucket policy, exposed security group, or vulnerable application still creates risk inside the cloud.

What the customer manages: security in the cloud

Customer responsibility commonly includes:

• IAM users, roles, policies, and credentials
• Passwords and multi-factor authentication
• Customer data and its classification
• Application code and dependencies
• Encryption choices and key-management configuration
• Network controls such as security groups and network ACLs
• Guest operating-system updates and security patches on self-managed compute
• Service-specific settings, logging, monitoring, and retention

The customer is also responsible for understanding the sensitivity of the workload and meeting applicable organisational, legal, and regulatory requirements. AWS services can provide security controls and compliance evidence, but they do not replace correct customer configuration.

Responsibility changes by service

The more infrastructure AWS abstracts and operates for you, the more responsibility moves to AWS. You still retain responsibility for your data, identities, permissions, and the configuration of the managed service.

Service	AWS generally manages	Customer generally manages
Amazon EC2	Physical infrastructure, host systems, and hypervisor	Guest OS, patches, applications, security groups, and data
Amazon RDS	Underlying infrastructure, operating system, and managed database platform	Database users, schema, data, access, settings, and maintenance decisions
Amazon S3	Storage infrastructure and platform software	Bucket policies, access, object data, encryption choices, and versioning
AWS Lambda	Infrastructure, execution environment, and managed runtime platform	Function code, dependencies, IAM role, environment variables, and data

The word “generally” matters. The final boundary depends on the service feature, deployment option, configuration, and applicable AWS documentation.

Example 1: Amazon EC2

EC2 gives the customer substantial control, so the customer also has more security work.

Suppose you launch an Ubuntu EC2 instance and install Nginx:

Responsibility	Owner
Replace failed physical RAM	AWS
Protect the physical server and data centre	AWS
Patch Ubuntu	Customer
Install and update Nginx	Customer
Configure security groups	Customer
Protect application credentials and data	Customer
Configure the application firewall and TLS	Customer

AWS provides the compute platform, but it does not administer the guest operating system or the software you install on the instance. A vulnerable package or an overly permissive security group is therefore a customer-side security issue.

Exam clue: If the question mentions guest OS patching, installed applications, or security-group configuration on EC2, choose the customer.

Example 2: Amazon RDS

RDS is a managed database service, so AWS manages more of the platform than it does for EC2. AWS operates the infrastructure, host systems, and managed database environment for supported configurations. The customer still controls the database as a service consumer.

The customer remains responsible for:

• Database users, passwords, and permissions
• Database schema and application queries
• Customer data and access patterns
• Network access and security-group rules
• Encryption and related key configuration where applicable
• Selecting maintenance windows and responding to service notifications

AWS may identify, validate, and release service patches, but the customer may still need to review updates, choose a maintenance window, or schedule a restart according to the service’s documented process.

Exam clue: Compared with EC2, RDS shifts operating-system and database-platform operations toward AWS, but it does not make the customer’s database users, data, or access configuration AWS’s responsibility.

Example 3: Amazon S3

For S3, AWS operates the storage infrastructure and the service platform. The customer controls how objects and buckets are used.

The customer must make deliberate decisions about:

• Bucket policies and IAM permissions
• Block Public Access settings
• Object ownership and access controls
• Encryption options and key policies
• Versioning, lifecycle rules, and retention
• Replication destinations and data-transfer choices

If a customer makes sensitive objects publicly readable through an incorrect policy, AWS did not choose that exposure. AWS provided the access-control mechanisms; the customer configured them incorrectly.

Exam clue: “An S3 bucket was accidentally made public” points to customer responsibility.

Example 4: AWS Lambda

Lambda removes much of the infrastructure and server-management work. AWS manages the underlying compute infrastructure and the execution platform, while the customer manages the function workload.

The customer is responsible for:

• Function code and third-party dependencies
• The execution role and permissions
• Environment variables and secret-handling choices
• Input validation and application security
• Data accessed or produced by the function
• Logging, monitoring, and retention choices

Lambda reduces the amount of infrastructure to secure; it does not remove the need to secure code, permissions, secrets, and data.

Shared controls: both sides have a role

Some controls are neither entirely AWS-owned nor entirely customer-owned. Patch management is a useful example:

• AWS patches and fixes flaws in the infrastructure it operates.
• The customer patches guest operating systems and applications on self-managed instances.
• For managed services, AWS may release service updates while the customer reviews notifications and selects maintenance windows or applies configuration changes where required.

Configuration management works similarly. AWS maintains the configuration of its infrastructure devices, while the customer configures guest operating systems, databases, applications, IAM, and network controls in the customer environment.

This is why checking a service’s specific documentation matters more than memorising a single universal diagram.

A practical website example

Imagine a website running on Ubuntu EC2 instances behind a load balancer:

• AWS secures the physical servers, data centres, host infrastructure, and hypervisor.
• The customer patches Ubuntu and Nginx.
• The customer configures security groups, network ACLs, TLS certificates, and application authentication.
• The customer protects database credentials and customer data.
• The customer monitors logs and responds to suspicious activity.

If the physical host fails, AWS handles the underlying infrastructure event. If the website uses a vulnerable Nginx version or permits public database access through an incorrect rule, the customer must remediate it.

Exam-ready decision process

When a question presents a security responsibility, use this sequence:

1. Identify the AWS service.
2. Ask whether the issue is physical infrastructure or customer configuration.
3. For EC2, include the guest OS and installed applications in customer responsibility.
4. For managed services, move platform operations toward AWS but keep data, IAM, permissions, and configuration with the customer.
5. Check whether the question describes an AWS-managed control, a customer-managed control, or a shared control.

Common answers to memorise:

• Physical data-centre security: AWS
• Hypervisor and host infrastructure: AWS
• EC2 guest OS patches: Customer
• IAM users and permissions: Customer
• S3 bucket policy: Customer
• Function code in Lambda: Customer
• Underlying infrastructure for RDS: AWS

Conclusion

The Shared Responsibility Model explains why AWS can secure the cloud platform without taking responsibility for every workload deployed on it. AWS protects the infrastructure; customers protect their identities, configurations, applications, and data. As services become more managed, AWS operates more of the platform, but the customer’s responsibility for secure use does not disappear.

For the exam, start with the core distinction—security of the cloud versus security in the cloud—then adjust the boundary based on the service. EC2 leaves more platform management with the customer; RDS, S3, and Lambda abstract more infrastructure while retaining customer responsibility for secure configuration and data use.

Sources

• AWS Well-Architected Framework: Shared responsibility
• AWS Shared Responsibility Model
• AWS Security: Shared responsibility model