The AWS shared responsibility model explained

When a company moves a workload to AWS, someone still has to patch operating systems, lock the doors of the data center, decide who can read the customer database and encrypt the backups. The question is who. The shared responsibility model is AWS's answer, and it is less a single rule than a line that moves depending on which service you use.

It is the first topic in the Cloud Practitioner exam's security domain and it keeps appearing in the Solutions Architect exam inside larger scenarios. Cloud Practitioner questions are usually direct: here is a task, whose job is it? Get the principle and four reference services clear and those questions become easy points.

Security of the cloud, security in the cloud

AWS states the split in two phrases.

AWS is responsible for security "of" the cloud: the physical data centers, the hardware, the global network, and the software that runs the services themselves, such as the hypervisor that isolates one customer's instances from another's.
The customer is responsible for security "in" the cloud: what they build on top. That always includes their data, who has access to it, and how their resources are configured.

The useful way to think about it: AWS owns everything you cannot touch. You cannot walk into a data center, replace a disk or patch the hypervisor, so those are always AWS's job. Anything you can configure through the console or an API is yours to configure correctly.

What never moves

Whatever service you use, some responsibilities stay put.

Always AWS: physical security of facilities, environmental controls such as power and cooling, hardware disposal, the network between AWS facilities, and the virtualization layer.
Always the customer: your data and how you classify it, IAM users, roles and policies, account credentials and MFA, deciding whether data is encrypted and with which keys, and the resource-level settings that control access (security groups, bucket policies, whether something is public).

A question that asks what is the customer's job "regardless of the service" is asking for an item from that second list. Configuring security groups and IAM permissions is the textbook answer.

How the line moves: four services

The more AWS manages, the less you do. The classic progression is infrastructure (EC2), managed services (RDS), and fully abstracted or serverless services (Lambda, S3, DynamoDB).

Amazon EC2: you run the server

EC2 gives you a virtual machine, and from the guest operating system upward it is yours. You patch the OS and everything installed on it, configure the host firewall and the security groups, harden the image, install and update the application, manage SSH keys or Session Manager access, choose whether EBS volumes are encrypted and back them up. AWS's job ends at the hypervisor and the physical host. If an unpatched web server on EC2 is compromised, that is the customer's failure, even though it ran on AWS hardware.

Amazon RDS: AWS runs the database server

Move the same database from EC2 to RDS and a large block of work changes hands. AWS now patches the host operating system and the database engine software, runs automated backups, and handles replication and failover for Multi-AZ deployments. You can't even log in to the OS.

You still own plenty: choosing the maintenance window (and applying optional updates), the security groups that decide who can connect, whether the instance is publicly accessible, encryption at rest and in transit, database users and their privileges, the schema, and tuning your own queries. AWS runs the database server; it does not run your database.

AWS Lambda: AWS runs the runtime

With Lambda there are no servers to see at all. AWS operates the hosts, the operating system, the execution environment and the managed language runtimes, and by default it applies runtime security updates to your functions automatically. You are responsible for your function code and the libraries you package with it, the permissions in the function's execution role, how secrets reach the function, and the data it handles. If you deploy a function as a container image, AWS publishes patched base images, but rebuilding and redeploying your image is on you.

Amazon S3: AWS runs the storage

S3 is an abstracted service: AWS operates the infrastructure, OS and platform, and stores your objects durably. Your part is access and data protection: bucket policies and IAM permissions, keeping Block Public Access on unless you truly need public objects, versioning and Object Lock if you need protection from deletion, and the encryption choice. Since January 2023 S3 encrypts every new object with S3-managed keys by default, so "encryption at rest" is now on out of the box, but choosing KMS keys, controlling who can use them, and who can read the data remain yours. A leaked bucket is almost always a customer configuration problem.

Shared and inherited controls

AWS also describes three kinds of controls, which Cloud Practitioner questions occasionally name.

Inherited controls come entirely from AWS: physical and environmental controls.
Shared controls apply at both layers, each party doing its own part. Patch management (AWS patches its infrastructure, you patch your guest OS and applications), configuration management (AWS configures its devices, you configure your OS, databases and applications) and awareness and training (AWS trains its staff, you train yours).
Customer-specific controls belong only to the customer, such as how data is zoned and routed within their own environments.

Compliance works the same way. AWS gets its infrastructure audited and publishes the reports (SOC, PCI DSS, ISO) in AWS Artifact; you use those reports as evidence, but your own workload still has to meet the standard.

How to answer these questions

Ask whether the task involves something physical or below the hypervisor. If so, it is AWS.
Ask whether it is about data, identities or access settings. If so, it is the customer, for every service.
For patching, identify the service. EC2: the customer patches the OS. RDS: AWS patches the OS and engine. Lambda: AWS patches the runtime. Application code is always the customer's.
For "which tasks move to AWS when migrating from EC2 to RDS (or to Lambda)", pick the infrastructure tasks: OS patching, engine or runtime patching, hardware, automated backups.
Watch for "shared". If the question asks which control is shared, patch management and configuration management are the standard answers.

Common exam traps

"AWS encrypts it, so encryption is AWS's job." AWS provides the encryption features; the decision to use them, and key management, is the customer's.
Managed means no customer duties. RDS still needs correct security groups, database users and backup retention settings. Managed shifts work, it does not remove it.
Security groups as an AWS duty. They are AWS features, but configuring them is always the customer's job, on EC2, RDS, Lambda in a VPC or anything else.
Physical answers in a customer list. Disposing of failed disks, data center access and hypervisor patching are never the customer's, however the option is worded.
Training. Each party trains its own employees; AWS does not train yours.
Query tuning on RDS. Slow SQL is the customer's problem. AWS runs the engine, not your application's queries.

A worked example

A company runs PostgreSQL on an EC2 instance and plans to move it to Amazon RDS for PostgreSQL. The security team asks what it can stop doing and what it must keep doing.

On EC2 the team patches Linux, upgrades PostgreSQL, scripts nightly backups, manages the security group and creates database roles. After the move, the first three move to AWS: RDS patches the host OS and applies engine updates in the maintenance window the team picks, and automated backups with point-in-time recovery replace the scripts. The security group stays with the team, as does deciding whether the instance is publicly accessible, turning on encryption at rest, creating database users and granting privileges, and fixing the reporting query that scans a large table. A Cloud Practitioner question asking "which two tasks become AWS's responsibility" wants OS patching and database software patching.