AWS Shared Responsibility Model

AWS Shared Responsibility Model: Who Secures What?

When you move to the AWS Cloud, security becomes a partnership. You don’t have to manage everything, but you can’t ignore everything either. Simply put: AWS protects the hardware and the global infrastructure, and you protect your data and configurations.

If AWS fails to secure the data center and a thief walks in, that is AWS’s fault. But if you leave your password as admin123 and get hacked, that is your fault.

The “Landlord vs. Tenant” Model Think of it as renting an apartment.

• AWS is the Landlord (Security OF the Cloud):
  • They own the building.
  • They ensure the walls are strong, the main gate has a security guard, the elevators work, and the electrical wiring is safe.
  • You don’t worry about fixing the roof or fighting off intruders at the main gate.
• You are the Tenant (Security IN the Cloud):
  • Once you get the keys to your flat, safety inside is your job.
  • You must lock your front door (Identity/Passwords).
  • You decide who visits you (Access Control).
  • If you bring a gas stove, you check for leaks (Patching software).
  • If you leave your door wide open and someone steals your TV, the Landlord (AWS) is not responsible.

the most critical rule to remember is: “AWS handles the physical stuff; you handle the digital stuff.”

The responsibility shifts depending on what service you use, but the core foundation remains the same.

• What AWS Handles (Security OF the Cloud):
  • Physical Security: Guards, fences, and biometric locks at AWS Data Centers.
  • Hardware: The actual physical servers, storage devices, and networking cables.
  • The Hypervisor: The software layer that allows multiple Virtual Machines (VMs) to run on one physical server.
  • Global Infrastructure: Maintaining Availability Zones (AZs) and Regions.
• What YOU Handle (Security IN the Cloud):
  • Customer Data: Your files, databases, and encryption.
  • Identity & Access Management (IAM): Creating users and roles using AWS IAM.
  • Operating System (OS): If you use EC2, you must update Windows or Linux.
  • Network & Firewall Configuration: Setting up Security Groups and NACLs.

Key Concept: If you use Amazon EC2 (Infrastructure as a Service), you have more work to do (patching OS). If you use Amazon S3 (Abstracted Service), AWS does more work (no OS for you to manage), and you just focus on data permissions.

Architect level, understanding the “Gray Area” is vital. It is not just about “Hardware vs. Data.” It is about Controls.

The Shared Responsibility Model breaks down IT controls into three categories:

1. Inherited Controls (AWS owns 100%):
   • You inherit these completely. Example: Physical access controls to data centers. You can download the AWS Artifact reports to prove to your auditors that AWS is doing this job.
2. Shared Controls (Both manage distinct parts):
   • Patch Management: AWS patches the infrastructure (firmware, hypervisor). You patch the Guest OS (in EC2) or Application dependencies.
   • Configuration Management: AWS configures the physical network devices. You configure the virtual network (VPC, Security Groups).
   • Awareness & Training: AWS trains their data center staff. You must train your developers on DevSecOps best practices.
3. Customer Specific Controls (You own 100%):
   • Zone Security (Data classification).
   • Application Logic (Code security).

Service Type Variance:

• IaaS (e.g., EC2, VPC): You do the heavy lifting (OS patching, firewall rules).
• PaaS (e.g., Amazon RDS): AWS manages the OS and database patching. You manage the database schema and user access.
• SaaS/Abstracted (e.g., S3, DynamoDB): AWS manages almost everything. You only manage Data + Permissions.

Use Cases

• Banking & Fintech: A bank uses AWS to host their core ledger. They rely on AWS for physical security (PCI-DSS compliance of the data center) but the bank’s DevSecOps team must encrypt the customer data using AWS KMS so even AWS engineers cannot read it.
• Healthcare: A hospital stores patient records on S3. They use the model to define that AWS ensures the hard drives don’t fail, but the hospital configures the S3 Bucket Policy to ensure patient data isn’t public.

1.4.1. Benefits

• Reduced Burden: You don’t worry about power supply, cooling, or physical guards.
• Faster Compliance: You inherit certifications (ISO 27001, SOC2) from AWS, so you don’t start from zero.
• Focus on Business: Your team focuses on code and customers, not racking servers.

 Technical Challenges

• The “Cloud is Secure” Myth: Many teams think, “We moved to AWS, so we are safe.” Wrong. AWS is secure, but your configuration might be weak.
• Shadow IT: Developers spinning up resources without telling the security team. These resources often lack patches or proper firewalls.
• Visibility: In a physical data center, you can see a blinking light. In AWS, if you don’t enable logging (AWS CloudTrail), you are flying blind.

1.5.1. Common Issues & Solutions

1.6. Official Documentation Hub

• AWS Shared Responsibility Model – Official Page
• AWS Security Best Practices Whitepaper
• AWS Compliance Programs (Artifact)

 Cheat Sheet