Curriculum Overview: AWS Shared Responsibility Model

This curriculum provides a structured path to mastering the AWS Shared Responsibility Model, a fundamental concept for the AWS Certified Cloud Practitioner (CLF-C02) exam. It defines the line of demarcation between the security measures that AWS implements and the security measures that customers must manage.

Prerequisites

Before starting this module, students should have a baseline understanding of:

Basic Cloud Concepts: Understanding of what the cloud is (On-demand delivery of IT resources).
Traditional IT Infrastructure: Knowledge of how physical data centers operate (servers, networking, and physical security).
AWS Global Infrastructure: Familiarity with Regions, Availability Zones (AZs), and Edge Locations.

Module Breakdown

Module	Title	Focus Area	Difficulty
1	Foundations of the Model	The "Of" vs "In" the Cloud distinction.	Beginner
2	AWS Responsibilities	Physical infrastructure, hardware, and managed software.	Beginner
3	Customer Responsibilities	Data protection, IAM, and Guest OS patching.	Intermediate
4	Shared & Shifting Controls	How responsibilities change across EC2, RDS, and Lambda.	Advanced

The Line of Demarcation

Loading Diagram...

Learning Objectives per Module

Module 1: Foundations

Define the Shared Responsibility Model and its value proposition.
Identify the "Line of Demarcation" between AWS and the customer.

Module 2: AWS Responsibilities (Security "OF" the Cloud)

Describe AWS's role in protecting the physical facilities (data centers).
Identify AWS's responsibility for the virtualization layer (hypervisor).
Understand how AWS manages the hardware and software for foundational services.

Module 3: Customer Responsibilities (Security "IN" the Cloud)

Describe the customer's role in securing their own data (encryption at rest/transit).
Define the customer's duty to manage Identity and Access Management (IAM).
Identify Guest Operating System (OS) maintenance requirements.

Module 4: Shifting Responsibilities

Differentiate between Inherited, Shared, and Customer-Specific controls.
Explain how moving from IaaS (EC2) to PaaS (RDS) or FaaS (Lambda) shifts more responsibility to AWS.

Examples: Responsibility Shifting

[!IMPORTANT] The more "managed" a service is, the more responsibility shifts to AWS. However, the customer always remains responsible for their data and IAM policies.

Service Type	Service Example	AWS Responsibility	Customer Responsibility
Unmanaged (IaaS)	Amazon EC2	Physical hardware, Hypervisor.	Guest OS Patching, Firewall (Security Groups).
Managed (PaaS)	Amazon RDS	OS Patching, Database Software updates.	Application Optimization, Data Encryption.
Serverless (FaaS)	AWS Lambda	Entire execution environment, scaling.	The Code itself, IAM triggers/permissions.

Real-World Scenario: The S3 Bucket

AWS Responsibility: Ensuring the physical hard drives in the S3 data center are secure and that the S3 API is available.
Customer Responsibility: Ensuring the bucket is not set to "Public" by mistake. If a customer leaves a bucket open and data is stolen, it is a Customer failure, not an AWS failure.

Success Metrics

To demonstrate mastery of this curriculum, the learner must:

Identify the Owner: Correctly attribute a security task (e.g., "Physical Security") to either AWS or the Customer in 100% of test scenarios.
Categorize Controls: Distinguish between Inherited (e.g., physical access), Shared (e.g., Patch Management), and Customer-Specific (e.g., Service/Comm Protection) controls.
Map the Shift: Explain why a user has less to manage on Amazon RDS compared to an EC2 instance running a MySQL database.

Real-World Application

Loading Diagram...

Risk Mitigation: By understanding the model, businesses avoid security gaps where they assume AWS is doing something that is actually their own responsibility.
Operational Efficiency: Organizations can choose highly managed services (like Lambda) to reduce their "security debt" and focus on writing business code rather than patching Linux kernels.