1.3. AWS Shared Responsibility Model

Every major cloud breach shares a common origin: someone assumed AWS handled a security control that actually fell on them. Without a clear mental model of where AWS's responsibilities end and yours begin, entire categories of protection — data encryption, identity policies, network configuration — fall through the cracks. Organizations that assume "AWS handles security" leave their data, identities, and configurations unprotected — while organizations that try to secure everything waste resources duplicating AWS's built-in protections. Think of it like renting an apartment: the landlord maintains the building's structure and plumbing, but you're responsible for locking your door, not leaving the stove on, and keeping your belongings safe. Would you blame the landlord if you left your front door wide open and got robbed? The shared responsibility model defines this exact boundary for cloud security.

This section clarifies the precise boundary between AWS's responsibilities and yours, and how that boundary shifts based on the service abstraction level.

Scenario: After a data breach, an organization discovers that their RDS database was publicly accessible. They argue AWS should have prevented this. Who is responsible?

Reflection Question: How does understanding the shared responsibility boundary help you determine which security controls YOU must implement versus which ones AWS handles automatically?