Mastering the AWS Shared Responsibility Model

This study guide explores the fundamental security framework of Amazon Web Services: The Shared Responsibility Model. Understanding this model is critical for any cloud practitioner, as it defines exactly where AWS's duties end and the customer's duties begin.

[!IMPORTANT] At AWS, Security is "Job Zero." This means it is the top priority for both AWS and the customer.

Learning Objectives

After studying this guide, you should be able to:

Differentiate between security "of" the cloud and security "in" the cloud.
Identify specific responsibilities for AWS (the provider) and the customer.
Explain how responsibility shifts based on the type of service (IaaS, PaaS, SaaS) used.
Understand how compliance certifications are "inherited" from the AWS infrastructure.

Key Terms & Glossary

Security "of" the Cloud: The responsibility of AWS to protect the infrastructure that runs all services offered in the AWS Cloud.
Security "in" the Cloud: The responsibility of the customer to secure the data, applications, and configurations they place onto the AWS infrastructure.
Inherited Controls: Security controls that a customer fully receives from AWS (e.g., physical security of a data center).
Shared Controls: Controls that apply to both the infrastructure layer and customer layers (e.g., Patch Management, Configuration Management).
Guest Operating System: The OS installed by the customer on a virtual machine (like Amazon EC2), which the customer is responsible for patching.

The "Big Idea"

The Shared Responsibility Model is a partnership. By offloading the "undifferentiated heavy lifting" of physical security and hardware maintenance to AWS, customers can focus their limited resources on innovation and securing their specific business data. It transforms security from a massive, solo burden into a shared effort where you leverage the multi-billion dollar security investment of Amazon.

Formula / Concept Box

Feature	Responsible Party	Analogy
Physical Infrastructure	AWS	The Landlord (Roof, Foundation)
Virtualization Layer	AWS	The Apartment Manager (Utilities)
Customer Data	Customer	The Tenant's Jewelry/Safe
Firewall (Security Groups)	Customer	The Tenant's Door Lock
Guest OS Patching	Customer	Cleaning the inside of the Apartment

Hierarchical Outline

AWS Responsibility: Security "OF" the Cloud
- Physical Security: Protection of Data Centers (guards, cameras, biometrics).
- Hardware: Maintenance of servers and storage devices.
- Software: The virtualization/hypervisor layer that creates virtual machines.
- Global Infrastructure: Protection of Regions, Availability Zones, and Edge Locations.
Customer Responsibility: Security "IN" the Cloud
- Data Protection: Encryption of data at rest and in transit.
- Identity & Access Management (IAM): Managing who has access to what.
- Guest OS: Patching and updating the operating system on EC2 instances.
- Network Configuration: Setting up Security Groups and Network ACLs.
Variations by Service Model
- Infrastructure as a Service (IaaS): Customer has the most responsibility (e.g., EC2).
- Platform as a Service (PaaS): AWS handles the OS and runtime; customer handles code (e.g., Lambda).
- Software as a Service (SaaS): AWS handles almost everything; customer handles data and access (e.g., AWS Artifact).

Visual Anchors

The Security Split

Loading Diagram...

Layered Security Approach

Compiling TikZ diagram…

⏳

Running TeX engine…

This may take a few seconds

Definition-Example Pairs

Term: Patch Management
- Definition: The process of updating software to fix vulnerabilities.
- Example: On an EC2 instance, the customer is responsible for running yum update or Windows Update. On Amazon RDS (a managed service), AWS is responsible for patching the underlying database engine.
Term: Configuration Management
- Definition: Setting up the environment to meet security standards.
- Example: AWS configures the physical infrastructure devices, but the customer must configure the Security Groups (virtual firewalls) to allow or block web traffic.

Worked Examples

Example 1: The EC2 Scenario (IaaS)

If you launch an Amazon EC2 instance running Linux:

AWS ensures the server hardware is powered on and the rack is physically locked.
AWS ensures the hypervisor software is secure.
YOU must SSH into the instance to update the kernel.
YOU must configure the Security Group to only allow traffic on Port 22 (SSH) from your IP.

Example 2: The Amazon S3 Scenario (Managed Service)

If you store files in an S3 bucket:

AWS manages the disk drives, the OS of the storage servers, and data durability.
YOU are responsible for clicking "Enable Encryption" and ensuring the bucket is not set to "Public" unless intended.

Checkpoint Questions

Which party is responsible for the physical security of the data center?
- Answer: AWS.
In the Shared Responsibility Model, what is the customer's responsibility regarding the Guest Operating System on an EC2 instance?
- Answer: Patching and security updates.
True or False: If AWS receives a SOC 2 compliance certification, the customer's application built on AWS is automatically compliant.
- Answer: False. The customer "inherits" the infrastructure certification, but must still perform their own audits for their application layer.
Who is responsible for managing IAM (Identity and Access Management) policies?
- Answer: The Customer (Security "in" the cloud).

[!TIP] A quick mnemonic: If you can touch it (hardware, floor, cables), AWS is responsible. If you can type it (data, code, configuration), YOU are responsible.

Muddy Points & Cross-Refs

Shared Controls Confusion: Some things are both. For example, Awareness & Training. AWS trains its employees; you must train your employees.
Service Variations: Don't assume all services have the same split. Always check if a service is "Managed" (like RDS or Lambda) or "Unmanaged" (like EC2) to know your duties.
Cross-Ref: See AWS Artifact to download the compliance reports that prove AWS is doing its part.