Shared Responsibility Model
The AWS Shared Responsibility Model divides security duties between AWS ("security OF the cloud" — physical, network, hypervisor) and the customer ("security IN the cloud" — OS, applications, data, IAM). The boundary shifts depending on the service type: IaaS gives customers more control, while managed services like RDS and Lambda shift more responsibility to AWS.
1. The Core Concept
The AWS Shared Responsibility Model is the foundation of security in AWS. It clearly divides who is responsible for what:
- AWS is responsible for "Security OF the Cloud" — the underlying infrastructure
- Customers are responsible for "Security IN the Cloud" — everything they deploy on the infrastructure
Both parties must fulfill their responsibilities for a workload to be truly secure.
2. AWS Responsibility — Security OF the Cloud
AWS protects the global infrastructure that runs all AWS services:
AWS always manages:
- Physical access controls — no customer ever visits an AWS data center
- Hardware procurement, installation, maintenance, and secure disposal
- Hypervisor patching (for EC2 shared tenancy)
- Managed service infrastructure: RDS underlying OS, Lambda execution environment, S3 storage layer
3. Customer Responsibility — Security IN the Cloud
Customers are responsible for configuring and securing what they deploy:
Customers always manage:
- Their data — what to store, whether to encrypt it, who can access it
- IAM users, groups, roles, policies, and MFA settings
- EC2 guest OS patches (inside the VM is entirely the customer's domain)
- Application code security and third-party dependencies
- Security group rules and network ACL configuration
- S3 bucket policies, versioning, and access settings
4. How Responsibility Shifts by Service Type
As services move from IaaS → PaaS → SaaS, AWS takes on more responsibility and customers have less to manage (but also less direct control):
| Service | AWS Manages | Customer Manages |
|---|---|---|
| EC2 (IaaS) | Hardware, hypervisor, host OS | Guest OS patches, middleware, app, data, security groups |
| RDS (Managed DB) | Hardware, OS, DB engine patches, automated backups | DB user accounts, schemas, queries, encryption settings |
| Lambda (Serverless) | Hardware, OS, runtime, scaling, patching | Function code, dependencies, IAM roles, event triggers |
| S3 (Object Storage) | Durability, hardware, storage infrastructure | Bucket policies, public access blocks, encryption, versioning |
| DynamoDB | Hardware, software, scaling, replication | Table design, access control, data stored |
5. Shared Areas — Both Parties Have a Role
Some responsibilities require action from both AWS and customers:
| Area | AWS Does | Customer Does |
|---|---|---|
| Patch management | Patches hypervisor and managed service internals | Patches EC2 guest OS and application software |
| Configuration management | Configures infrastructure components securely | Configures their own AWS resources and services |
| Awareness and training | Trains AWS employees on security | Trains their own team on AWS security best practices |
6. Real-World Exam Scenarios
Scenario: An RDS database is breached via a known DB engine vulnerability
- AWS responsibility: Patching the DB engine — AWS manages RDS engine patches
- Customer responsibility: Restricting security group rules to only required IPs — customer manages network access
Scenario: An EC2 instance is compromised via an unpatched OS vulnerability
- AWS responsibility: The hypervisor prevented the attack from spreading to other tenants — AWS managed correctly
- Customer responsibility: The guest OS was unpatched — customer is responsible for patching EC2 guest OS
Scenario: Sensitive data in S3 is publicly exposed
- AWS responsibility: AWS provided S3 durability and the tools to restrict access
- Customer responsibility: The customer misconfigured the bucket policy — customer manages S3 bucket permissions
7. CLF-C02 Quick Reference
| Topic | Key Fact |
|---|---|
| AWS phrase | "Security OF the cloud" |
| Customer phrase | "Security IN the cloud" |
| AWS always manages | Physical security, hardware, hypervisor, managed service internals |
| Customer always manages | Data, IAM configuration, EC2 guest OS, application code, security groups |
| EC2 (IaaS) | Customer manages OS and everything above the hypervisor |
| RDS (Managed) | AWS patches DB engine; customer manages schema and data |
| Lambda (Serverless) | AWS manages runtime; customer manages function code and IAM |
| S3 | AWS provides durability; customer manages bucket policies and encryption settings |
| Shared areas | Patch management, configuration management, awareness and training |
| Responsibility shift | More managed service = AWS takes more responsibility |
Practice Questions6
Q1. Under the AWS Shared Responsibility Model, which of the following is AWS SOLELY responsible for?
Select one answer before revealing.
Q2. A company runs its application on Amazon EC2 instances. Under the Shared Responsibility Model, which of the following is the CUSTOMER's responsibility?
Select one answer before revealing.
Q3. A company recently migrated their database from EC2 (self-managed) to Amazon RDS. How does the Shared Responsibility Model change with this move?
Select one answer before revealing.
Q4. Which of the following BEST describes a SHARED responsibility between AWS and the customer for Amazon EC2?
Select one answer before revealing.
Q5. A company uses AWS Lambda for their entire backend. How does the Shared Responsibility Model differ from using Amazon EC2?
Select one answer before revealing.
Q6. Under the AWS Shared Responsibility Model, which of the following does NOT fall under AWS's responsibility?
Select one answer before revealing.