AWS Shared Responsibility Model

The one-liner

If you can TOUCH it (SSH, console config, your data) → YOUR responsibility
If you can't REACH it (hypervisor, engine internals, data center) → AWS's

The split

CUSTOMER (security IN the cloud):
  • Data + client-side encryption
  • Server-side encryption decisions (enable it, choose keys)
  • Network traffic protection (SG/NACL config)
  • OS, middleware, apps (on EC2)
  • IAM: users, roles, policies
  • Anything you configure

AWS (security OF the cloud):
  • Physical data centers, hardware
  • Regions / AZs / edge locations
  • Hypervisor (VM isolation)
  • Managed service internals (S3, RDS engine, Lambda runtime)

Boundary moves by service type

Service	You (touch)	AWS (can’t reach)
EC2	OS, patches, apps, firewall, data	Hardware, hypervisor
RDS	Data, schema, IAM, backups on/off	OS, engine, patches
S3	Data, bucket policies, encryption choice	Everything else
Lambda	Code, IAM, config	Runtime, infra, scaling

Test questions

• SSH into EC2? → yes → OS patching = YOU
• SSH into RDS? → no → engine patching = AWS
• S3 bucket settings? → yes → public bucket leak = YOU
• Walk into data center? → no → physical = AWS
• Edit Lambda code? → yes → code bugs = YOU

Related

• [[aws/index]]
• [[aws/security-services/index]]