The AWS Shared Responsibility Model: Who Secures What

Guides › Study topics

Updated 1 Nov 2026 · 7 min read

On this page

1. Security of the cloud versus security in the cloud
2. How your share changes from service to service
3. Amazon RDS compared with a database on EC2
4. Inherited, shared and customer-specific controls
5. A worked example: one application, three designs
6. How this fits your exam
7. Frequently asked questions
8. Sources

By the end of this page you will be able to say which security tasks AWS owns and which ones you own for a given service, explain why the split moves when you switch from Amazon EC2 to Amazon RDS, AWS Lambda or Amazon S3, and sort controls into the three groups AWS uses: inherited, shared and customer specific. Everything here comes from AWS's own shared responsibility page, service documentation and exam guides.

Security of the cloud versus security in the cloud

AWS describes security and compliance as a shared responsibility between AWS and the customer. AWS operates, manages and controls the components from the host operating system and virtualisation layer down to the physical security of the facilities where the service runs. AWS calls its side "security of the cloud": protecting the infrastructure that runs all of the services offered in the AWS Cloud, which it defines as the hardware, software, networking and facilities that run those services.

Your side is "security in the cloud". AWS says your responsibility is determined by the AWS services you select, and that the choice of service determines how much configuration work you must do as part of your security responsibilities. The page also tells customers to think carefully about the services they choose, because responsibilities vary with the services used, how they are integrated into your IT environment, and the laws and regulations that apply.

A useful way to hold this in your head: for the services on this page, AWS owns everything from the host operating system and virtualisation layer down to the facilities. How far above that AWS's share reaches depends on the service you choose.

How your share changes from service to service

Amazon EC2. AWS classifies EC2 as Infrastructure as a Service (IaaS), which requires you to perform all of the necessary security configuration and management tasks. If you launch an instance, you manage the guest operating system (including updates and security patches), any application software or utilities you install, and the configuration of the AWS-provided firewall, called a security group, on each instance. The EC2 user guide adds managing the credentials used to connect to your instances and configuring the IAM roles attached to them.

Amazon S3. AWS calls S3 and Amazon DynamoDB abstracted services. For these, AWS operates the infrastructure layer, the operating system and the platforms, and you access endpoints to store and retrieve data. You are responsible for managing your data (including encryption options), classifying your assets and using IAM tools to apply the right permissions. The S3 user guide also lists enabling detective controls such as AWS CloudTrail or Amazon GuardDuty for S3 as part of your share.

AWS Lambda. The Security Overview of AWS Lambda whitepaper says AWS manages the underlying infrastructure and foundation services, the operating system and the application platform. You are responsible for the security of your code and for AWS IAM, both to the Lambda service and within your function. Runtime patching is split further. For managed runtimes, Lambda publishes new runtime versions containing the latest patches. With the Auto runtime update mode, Lambda also applies them to your functions. With Function update mode, you must update your functions regularly to pick up the latest runtime. With Manual mode, you are responsible for moving to the latest runtime version. If you deploy your function as a container image, Lambda publishes updated base images and you are responsible for rebuilding your image from the latest base image and redeploying it. If you implement a custom runtime, maintaining it and keeping its security patches current becomes your responsibility.

Amazon RDS compared with a database on EC2

The clearest illustration is AWS's own comparison of running a relational database on premises, on EC2 or on Amazon RDS. The table below reproduces the management model from the Amazon RDS user guide.

Several things stay with you on RDS. The first is application optimisation, which is yours in every column. The second is query tuning: the RDS guide says you are responsible for adjusting SQL queries to improve performance, and that monitoring and tuning are processes you own. Access control also stays with you. You can define users and permissions with IAM, and a security group controls access to a DB instance by allowing the IP address ranges or EC2 instances that you specify.

Read the AWS column as who carries out the task, not as something that happens without any choice from you. The same guide says you can turn on automated backups, and that you can get high availability with a primary DB instance and a synchronous secondary DB instance that you can fail over to when problems occur.

Inherited, shared and customer-specific controls

AWS extends the model to IT controls, and sorts them into three groups.

• Inherited controls are ones you fully inherit from AWS. AWS gives physical and environmental controls as the example.
• Shared controls apply to both the infrastructure layer and the customer layers, but in completely separate contexts. AWS provides the requirements for the infrastructure and you provide your own implementation within your use of AWS services.
• Customer-specific controls are solely your responsibility, based on the application you deploy. AWS's example is service and communications protection, or zone security, which may require you to route or zone data within specific security environments.

AWS gives three examples of shared controls. In patch management, AWS patches and fixes flaws in the infrastructure and you patch your guest operating system and applications. In configuration management, AWS maintains the configuration of its infrastructure devices and you configure your own guest operating systems, databases and applications. In awareness and training, AWS trains its employees and you must train yours.

People often read "shared" as "both parties do the same job together". That is not what AWS means. Each party does the same kind of task, on its own layer. AWS training its staff does not train yours.

A worked example: one application, three designs

Suppose you run a web application backed by a MySQL database. Here is how the work moves as you change the design, using only the sources above.

1. MySQL on an EC2 instance. You patch the guest operating system, install and patch MySQL, take the database backups, and build high availability and scaling yourself. AWS handles server maintenance, the hardware lifecycle, and power, network and cooling.
2. The same database on Amazon RDS. In AWS's management model, operating system patching, database software installation and patching, backups, high availability and scaling move to AWS. The guide still presents automated backups as something you can turn on, and high availability as a primary DB instance with a synchronous secondary. You still own application optimisation, query tuning and who can reach the instance.
3. Move the application tier to Lambda. AWS now manages the operating system and application platform under your code. You own the code and the IAM permissions, and on a managed runtime, whether runtime patches reach your functions automatically depends on the runtime update mode you choose.

Notice what never moves: in every design you still decide who has access, through IAM and, where the service has them, security groups.

How this fits your exam

AWS CLF-C02. Content Domain 2, Security and Compliance, represents 30% of the scored content. Task Statement 2.1 is "Understand the AWS shared responsibility model". Its skills include describing the customer's responsibilities, AWS's responsibilities and the responsibilities they share, and "Describing how AWS responsibilities and customer responsibilities can shift, depending on the service used (for example, Amazon RDS, AWS Lambda, Amazon EC2)". Our CLF-C02 study guide covers the rest of the exam.

AWS SAA-C03. Content Domain 1, Design Secure Architectures, is 30% of the scored content. Task 1.1, "Design secure access to AWS resources", lists "The AWS shared responsibility model" under its knowledge items. See the SAA-C03 study guide for the other domains.

Frequently asked questions

Is patching AWS's job or mine?

Both, which is why AWS lists patch management as a shared control. AWS patches the infrastructure. On EC2 you patch the guest operating system and your applications. On RDS, AWS patches the operating system and the database software. On Lambda managed runtimes, AWS publishes runtime patches, and who applies them depends on the runtime update mode.

Who is responsible for encrypting data stored in Amazon S3?

Managing encryption is your responsibility: for S3, AWS says your share includes managing your data, including object ownership and encryption, as well as classifying your assets and managing access with IAM. You do not start from nothing, though. Amazon S3 applies server-side encryption with Amazon S3 managed keys (SSE-S3) as the base level of encryption for every bucket, and since 5 January 2023 all new object uploads are encrypted automatically. If you need more control over your keys, such as managing key rotation and access policy grants, choosing SSE-KMS or DSSE-KMS is up to you.

Does my share change with the Region I use?

It can. AWS says customer responsibility varies with many factors, including the AWS services and Regions you choose, how those services integrate into your IT environment, and the laws and regulations that apply to your organisation and workload.

Sources

• Shared Responsibility Model
• What is Amazon Relational Database Service (Amazon RDS)?
• Security Overview of AWS Lambda
• Understanding the shared responsibility model for Lambda runtime management
• Security in Amazon S3
• Content Domain 2: Security and Compliance

Test yourself on the model with the free CLF-C02 practice questions, then work through the CLF-C02 study guide.