AWS shared responsibility model explained
The AWS shared responsibility model explained: security of vs in the cloud, inherited, shared and customer controls, and how it shifts across EC2, RDS and S3.
The shared responsibility model is one of the most reliably tested ideas on the AWS Cloud Practitioner exam. It sits inside Security and Compliance, the 30% domain, and it also shows up in questions about databases, containers and storage. The idea is simple. The difficulty is that the answer changes depending on which service the question names.
The two halves
AWS is responsible for security of the cloud. The customer is responsible for security in the cloud.
- Of the cloud: the infrastructure that runs AWS services. AWS operates and controls everything from the host operating system and virtualization layer down to the physical security of its facilities. That includes data center buildings, servers and storage hardware, network equipment, and power and cooling.
- In the cloud: what the customer puts into AWS and how they set it up. That covers data, identities and permissions, the guest operating system on EC2, application code, security group rules, and encryption choices.
A quick test that works on most questions: if the task is about the facility, the hardware or the virtualization layer, it is of the cloud and belongs to AWS. If it involves your data, accounts, code or settings, it is in the cloud and belongs to you.
Responsibility is determined by the service you choose. The more of the stack AWS operates for a service, the less you manage, but you never get to hand off everything.
Three kinds of control
AWS describes the controls in three groups:
| Type | Meaning | Example |
|---|---|---|
| Inherited | The customer fully inherits the control from AWS | Physical and environmental security of data centers |
| Shared | Applies to both AWS and the customer, in different contexts | Patch management, configuration management, awareness and training |
| Customer-specific | Belongs to the customer alone | Service and communications protection or zone security, such as routing data within specific security environments |
The shared controls are worth reading carefully, because the exam likes them. For patch management, AWS patches and fixes flaws in its infrastructure, while customers patch their guest operating system and applications. For configuration management, AWS maintains its infrastructure devices, while customers configure their guest OS, databases and applications. For awareness and training, AWS trains AWS employees and customers train their own.
How it shifts by service
This is where most points are won or lost. The same question, such as "who patches the operating system", has a different answer on different services.
| Service | AWS handles | Customer handles |
|---|---|---|
| Amazon EC2 | Hardware, physical facility, virtualization layer | Guest OS and its patches, installed software, security groups |
| Amazon RDS | Infrastructure, OS and database engine patching, backups and failure recovery | Query tuning, network access (VPC and security groups), IAM permissions, turning on encryption |
| Amazon S3 | Infrastructure, OS and platform | Data, object ownership, encryption, permissions with IAM, detective controls such as CloudTrail |
| Amazon DynamoDB | Guest OS and database patching, firewall configuration, disaster recovery | Data and access with IAM, choice of encryption key type |
| AWS Lambda | Managed runtimes and base images, patched automatically by default | Function code and its dependencies |
| ECS on Fargate | Provisioning and patching the compute infrastructure | Network configuration, storage encryption, container images, task IAM role |
| Amazon EKS | The Kubernetes control plane | Data plane configuration, node OS patches (unless Auto Mode), security groups, IAM |
A few details come up repeatedly:
- EC2 is the "customer patches the OS" example. Install your own database on EC2 and you patch both the OS and the database software. Move it to RDS and AWS takes over that patching and the backups, which is a favorite scenario.
- RDS still leaves the customer with the application. Query tuning stays with you.
- Lambda container images are different from managed runtimes. For a managed runtime, AWS applies patches automatically by default. If the function is packaged as a container image, you must rebuild and redeploy from the latest base image. And if a runtime is deprecated, AWS's patching duty ends and you must upgrade.
- Fargate removes host management. Moving from containers on EC2 to Fargate hands host patching to AWS, but container image security stays yours.
Across all of these, the customer always keeps data, identities and permissions. A managed service does not mean AWS configures your IAM policies or classifies your data. Moving to Lambda or S3 reduces patching duty but never removes data and access duties.
Common traps
- "AWS is certified, so compliance is covered." A third-party audit of AWS verifies AWS's controls. The customer remains responsible for classifying their data and for compliance with laws about it.
- "Security groups are AWS's job." AWS provides the firewall; the customer decides which ports open.
- Mixing up shared and inherited. Physical security is inherited, with no customer part. Patching has an AWS part and a customer part, so it is shared.
- Applying one service's answer to another. "Who patches the OS?" is the customer on EC2 and AWS on RDS.
Practicing it
Work through scenarios: a security group left open to the internet is the customer's problem; a failed disk in a data center is AWS's; a vulnerable third-party library in a Lambda function is the customer's, but a Python runtime patch is AWS's by default. The Encodr course has a whole unit on this, three chapters covering the basics, how responsibility shifts by service, and scenarios.
The AWS Cloud Practitioner flashcards include that unit as part of the Security and Compliance domain. Cards are recall practice, not a replacement for looking at these services in the AWS console, and the course is unofficial and not affiliated with or endorsed by AWS. If you want to see these as exam-style questions, the practice questions include several. For the larger picture, see what is on the exam and how to study for it, and for the learning method behind retrieval practice, the testing effect.
The Azure fundamentals exam teaches the same idea for Microsoft's cloud; AWS vs Azure: which cloud cert first compares the two.
Encodr turns this into a habit: study anything in a feed, and it schedules the rest.
Get started free