The AWS shared responsibility model, and how it shifts between EC2, RDS and Lambda

Why this matters

When a company runs its own data centre, every security task is its own, from the lock on the door to the password on the database. When it moves to AWS, some of those tasks pass to AWS and some do not. The shared responsibility model is AWS's statement of where that line falls. Getting it wrong is how real breaches happen: a team assumes that because Amazon S3 is a managed service, AWS will stop anyone reading a bucket, and then leaves the bucket open to the public. AWS ran the storage perfectly. The exposure was the customer's.

For a manager, the model answers the auditor's question "who does this control?". For a salesperson, it answers the customer who asks whether moving to AWS means they no longer have to think about security; it does not. For a junior engineer, it says which patches are theirs to apply. The Security and Compliance domain is 30% of the scored content, and this model sits under almost every topic in it.

The lesson

AWS shared responsibility model

AWS divides security and compliance into two halves, and it uses two short phrases for them.

• Security of the cloud is AWS's half. AWS protects the infrastructure that runs every AWS service: the facilities, the hardware, the networking and the software that makes up the services themselves.
• Security in the cloud is the customer's half. The customer protects what it puts into AWS and how it configures it: its data, its identities and permissions, its settings, and any software it installs.

A rough comparison is a secure storage building. The operator guards the building, maintains the walls and keeps the lifts running. The tenant decides what goes in their unit, who is given a key and whether the door is locked. The operator cannot decide who the tenant trusts.

One rule governs the whole model: the customer's share depends on the services it chooses. The more AWS manages in a service, the less the customer has to do. That is why the same task, such as patching an operating system, can belong to the customer on one service and to AWS on another.

The components of the model

AWS's own diagram of the model has two layers. Learn the components, because questions often name one and ask which side it belongs to.

AWS's layer, security of the cloud:

• The AWS global infrastructure: Regions, Availability Zones and edge locations (lesson 13 explains each). Customers choose which Regions to use, but they do not secure the infrastructure.
• Hardware: the physical servers, storage devices and network equipment.
• Software for the foundation services: compute, storage, database and networking.
• Facilities: the data centre buildings, their power, cooling and physical security.

The customer's layer, security in the cloud, from the top down:

• Customer data.
• Platform, applications, and identity and access management.
• Operating system, network and firewall configuration.
• Client-side data encryption and data integrity authentication: protecting data before it is sent to AWS.
• Server-side encryption of file systems or data: choosing to have the AWS service encrypt data once it arrives.
• Network traffic protection: encryption, integrity and identity for data in transit.

AWS also groups IT controls into three types. Inherited controls are ones the customer takes over fully from AWS: physical and environmental controls. Shared controls apply to both layers, with each party doing its own part. Customer-specific controls are the customer's alone, such as deciding that certain data must be kept and routed only within particular security zones.

Describing the customer's responsibilities on AWS

Some responsibilities stay with the customer on every service, whether it is a virtual server or a fully managed one.

• Data. The customer owns its data, so it classifies it and decides how to protect it. AWS does not know what the data is, so it cannot classify it, even when the data sits in a managed service such as S3.
• Identity and access management. The customer decides which users and roles can do what, using AWS Identity and Access Management (IAM). That includes protecting the root user's credentials: AWS creates the account, but it does not hold or guard the customer's passwords. Lessons 9 and 10 cover IAM and the root user.
• Configuration. S3 bucket policies, security groups, network ACLs and VPC route tables are all customer settings. A bucket left publicly readable is the customer's responsibility, and access control is not a shared control.
• Encryption choices. The customer decides whether to encrypt. For Amazon EBS volumes, the company turns encryption on per volume or sets it as the default for its account in each Region; AWS provides the feature and the key infrastructure. Encrypting data before it leaves the company's network is client-side encryption, a customer duty, because server-side encryption only starts once data reaches the service. Encrypting traffic between users and an application on EC2 is network traffic protection, also the customer's. Lesson 8 covers encryption in depth.
• Where data is stored. The customer chooses the Region for its content. AWS does not move customer content out of that Region without the customer's agreement, except where the law requires it. AWS does not pick a Region for the customer.
• Compliance of its own workload. If a payment workload runs on AWS services that are in scope for PCI DSS, the workload is not compliant just because AWS is certified. AWS's certification covers the infrastructure it runs; the company must still configure and operate its own workload compliantly. Lesson 7 covers compliance.

Physical security is normally AWS's, but there is one exception to know. With AWS Outposts, AWS racks sit inside the customer's own facility. AWS owns and maintains the Outposts hardware, but the customer is responsible for the physical security, access, power and networking of its own site.

Describing AWS responsibilities

AWS is responsible for everything the customer cannot reach.

• Physical data centres: the buildings, the guards, the access controls, power and cooling.
• Hardware: the host servers and storage devices, including replacing failed disks.
• The host operating system and the hypervisor, the virtualisation layer that keeps one instance isolated from another. On EC2, AWS secures everything up to and including the hypervisor; the customer's responsibility begins at the guest operating system.
• The physical network: the cabling, the routers in AWS data centres, the global backbone, and the isolation of one customer's traffic from another's. Inside a VPC, AWS protects the physical network underneath while the customer writes the rules.
• Media destruction: when a storage device that held customer data reaches the end of its life, AWS decommissions it with its own documented process. Customers do not handle the decommissioning of the devices in AWS's data centres.
• The managed services themselves: for S3, AWS runs the storage servers, patches the software that runs S3 and replicates objects across devices so they are durable. For Amazon DynamoDB, AWS operates and patches the servers, storage and software behind the tables.

Responsibilities the customer and AWS share

Three controls are shared. In each, AWS does its part for the infrastructure and the customer does its part for what it controls. Neither party does the whole job.

• Patch management. AWS patches and fixes flaws in its infrastructure. The customer patches its own guest operating systems and applications. On EC2, that includes every third-party application the company installs: if a vulnerability is announced in one, the company applies the fix, not AWS and not AWS Support.
• Configuration management. AWS configures its infrastructure devices. The customer configures its own guest operating systems, databases and applications. Neither can reach the other's layer.
• Awareness and training. AWS trains its own employees. Each customer trains its own staff. Training customer staff is not AWS's responsibility, and customers have no part in training AWS personnel.

Do not confuse shared with inherited. Physical and environmental controls are inherited in full: AWS operates them for its facilities, and in an audit the customer relies on AWS's audit evidence for them. Media destruction works the same way.

A shared control does not mean "half each" for every task. Data classification and access control are not shared at all; they are the customer's.

How responsibility shifts with the service: Amazon EC2, Amazon RDS and AWS Lambda

The clearest way to see the model move is to follow one application across three services.

Amazon EC2 is infrastructure as a service: AWS gives the customer a virtual server and the customer runs everything on it. The customer patches the guest operating system, installs and patches applications, configures security group rules (its firewall), chooses whether to encrypt its EBS volumes, and protects its data and permissions. AWS secures the physical hosts, the hypervisor and the network. Moving from on-premises servers to EC2 removes the building, the hardware and the network devices from the company's list, but the guest operating system and firewall rules stay.

Using an AWS tool does not change this. If the company patches its EC2 instances with AWS Systems Manager, the tool helps, but patching the guest operating system is still the company's duty.

Amazon RDS is a managed database service. When a company moves a database it ran itself on EC2 to RDS, AWS takes over installing and patching the database engine and the operating system underneath it, and maintaining the hardware. The company still creates database users and grants their privileges, controls network access with security groups, decides whether to encrypt, and manages its database settings and data. High availability shows the split neatly: the customer decides whether to deploy with Multi-AZ, and once it does, AWS manages the standby copy, the replication and the automatic failover. AWS does not switch Multi-AZ on by itself.

AWS Lambda is serverless compute: the customer uploads code and AWS runs it. AWS manages the servers and their operating systems, keeps the managed language runtimes patched, and scales capacity automatically as invocations grow. The customer is left with what it brings: the function code and its dependencies, the permissions in each function's execution role, the secrets the code reads, and the data it handles. A company that rewrites an application from EC2 to Lambda gives up operating system patching, but secure code, least-privilege permissions and data protection remain its own.

Other services follow the same pattern. AWS Fargate, serverless compute for containers on Amazon ECS and Amazon EKS, moves the management and patching of the underlying servers to AWS, while the company secures its container images and the IAM permissions of its tasks (lesson 15). S3 and DynamoDB are managed in the same way as Lambda: AWS runs the infrastructure, the operating system and the platform, and the customer manages its data and who can reach it.

So the order from the most customer security work to the least is EC2, then RDS, then Lambda. What never moves, on any of them, is the customer's data, its identities and permissions, and its configuration of access.

What the exam is really asking

Most questions name a task and ask whose it is. Ask two things. First: can the customer physically or technically reach this layer? Buildings, hosts, hypervisors, physical networks and the software inside a managed service are out of the customer's reach, so they are AWS's. Second: is this about the customer's own data, identities or settings? Then it is the customer's, whatever the service. Only when a task is a guest operating system or platform software, such as a database engine or a language runtime, does the service matter: the customer's on EC2, AWS's on RDS, Lambda and Fargate. And when a question asks what is shared, the answer comes from a short list: patch management, configuration management, and awareness and training.