What is the shared responsibility model?

The AWS Shared Responsibility Model is the foundational framework that defines who is responsible for what in cloud security. Think of it like renting an apartment: the landlord (AWS) is responsible for the building structure, plumbing, electrical wiring, and foundation. The tenant (you) is responsible for locking the doors, not leaving the stove on, and choosing who gets a key. If the building foundation cracks, that is the landlord's problem. If you leave the front door wide open and get robbed, that is your problem.

AWS's responsibility is security OF the cloud. This encompasses four layers. First, the physical layer: data center buildings with biometric access, 24/7 security guards, CCTV, mantraps, and physical destruction of decommissioned disks. AWS data center locations are undisclosed and undergo SOC1, SOC2, SOC3, ISO 27001, PCI-DSS, and FedRAMP audits. Second, the infrastructure layer: the global network backbone, edge locations, Availability Zones, and Regions. AWS manages the fiber optic connections between AZs (encrypted in transit), the redundant power supplies, and the cooling systems. Third, the compute layer: the Nitro hypervisor that isolates your EC2 instances from other tenants. AWS patched Spectre and Meltdown at the hypervisor level. Fourth, the managed services control plane: when you use RDS, AWS patches the database engine. When you use Lambda, AWS patches the runtime. When you use S3, AWS ensures the storage layer is resilient.

Your responsibility is security IN the cloud, and this is where most breaches happen. The exact scope depends on the service abstraction level. For IaaS services like EC2, you are responsible for: the guest operating system (patching Amazon Linux, Ubuntu, or Windows), the application stack running on it, security group and NACL configurations, host-based firewalls, antivirus, data encryption at rest and in transit, and IAM policies. For container services like ECS or EKS, AWS manages the underlying EC2 instances (if using Fargate) or you manage them (if using EC2 launch type). You always own the container images, application code, and network policies. For abstracted services like S3, Lambda, and DynamoDB, AWS handles much more — you are responsible for bucket policies, function permissions, data classification, encryption key management, and access logging configuration.

The most critical customer responsibilities that cause real breaches

1. S3 bucket misconfiguration: Setting bucket policies to public access has caused multiple high-profile data breaches. AWS added S3 Block Public Access as an account-level setting specifically because so many customers misconfigured bucket policies.

2. IAM over-permissioning: Granting AdministratorAccess or using wildcard (*) permissions instead of least privilege. A compromised application with broad IAM permissions can pivot to access any resource in the account.

3. Unpatched EC2 instances: AWS patches the hypervisor, but if you run a vulnerable version of Apache on your EC2 instance and it gets exploited, that is your responsibility. You should use AWS Systems Manager Patch Manager to automate OS patching.

4. Unencrypted data: AWS provides the encryption tools (KMS, ACM, CloudHSM), but you must choose to use them. Leaving an EBS volume or RDS instance unencrypted is your responsibility.

5. Missing logging: AWS provides CloudTrail, VPC Flow Logs, and S3 Access Logs, but you must enable and monitor them. Many organizations enable CloudTrail but never review the logs.

The model also extends to compliance. AWS provides compliance-eligible infrastructure (HIPAA, PCI, FedRAMP), but achieving compliance for your application requires you to configure services correctly and implement the required controls. AWS Artifact provides compliance reports, and services like AWS Config Rules and Security Hub help automate compliance checking. The shared responsibility model is not just a concept — it is the legal and operational framework that determines liability when something goes wrong.