AWS Shared Responsibility Model: Navigating Shifting Responsibilities

This curriculum overview details the division of security obligations between AWS and the customer. It highlights how these responsibilities shift as you move from unmanaged services like Amazon EC2 to managed services like Amazon RDS and serverless options like AWS Lambda.

Prerequisites

Before starting this curriculum, students should have a foundational understanding of the following:

• Basic Cloud Concepts: Understanding of "the cloud" as on-demand delivery of IT resources.
• AWS Global Infrastructure: Knowledge of Regions, Availability Zones, and Edge Locations.
• Common AWS Service Categories: Familiarity with what Compute, Storage, and Database services are at a high level.

Module Breakdown

Learning Objectives per Module

Module 1: The Foundation

• Define the Shared Responsibility Model.
• Distinguish between AWS's responsibility for infrastructure and the customer's responsibility for data and configuration.

Module 2 & 3: Shifting Responsibilities

• Compare the management overhead of Amazon EC2 vs. Amazon RDS.
• Explain who is responsible for patching the Operating System in different service models.

Module 4: Serverless

• Identify why AWS Lambda represents the highest level of AWS-managed security.
• Describe the customer's role in securing code and data outputs in a serverless environment.

Success Metrics

To demonstrate mastery of this curriculum, the learner must be able to:

1. Correctly Categorize Tasks: Assign a list of 20 security tasks (e.g., "Physical security of data centers" vs "Patching Windows Server") to either AWS or the Customer.
2. Architecture Selection: Given a business requirement for "minimal administrative overhead," select the appropriate service (Lambda vs EC2) and justify the choice based on the responsibility shift.
3. Audit Readiness: Explain where to find compliance reports (AWS Artifact) to verify AWS's side of the shared responsibility.

Real-World Application

In a professional setting, understanding this model is critical for Risk Management and Operational Efficiency.

• Cloud Architect: Designing systems that minimize the "surface area" the internal team must manage by leveraging managed services.
• Security Analyst: Ensuring that the organization is actually performing the patches and configuration audits that AWS does not do for them.
• Cost Optimization: Recognizing that while managed services might have a higher sticker price, they reduce the "Total Cost of Ownership" (TCO) by offloading labor-intensive security tasks to AWS.

Examples: The Responsibility Shift

As you move from unmanaged to serverless, the "line" of responsibility moves upward, with AWS taking over more of the stack.

Comparison Table: Who Patches What?

[!IMPORTANT] The Rule of Thumb: "If you can edit it, you own it."

Visualizing the Shift

Key Control Types

• Inherited Controls: Controls you get for free.
  • Example: You don't need to hire security guards for the data center; you inherit this from AWS.
• Shared Controls: Both parties play a role in different contexts.
  • Example: Patch Management. AWS patches the host/physical layer; you patch the guest OS (EC2) or AWS patches the DB engine (RDS).
• Customer-Specific Controls: Entirely your problem.
  • Example: Service and Communications Protection. How you route traffic within your VPC subnets.