AWS Shared Responsibility Model (Task 2.1)

AWS Shared Responsibility Model

Security and compliance are shared between AWS and you. AWS secures the underlying cloud; you secure what you put in it. The exam asks "Whose job is this?" for every control; senior engineers use the model to assign blame correctly in post-mortems, to scope compliance work, and to know exactly where their patching duty ends.

AWS Responsibilities — "Security OF the Cloud"

Brief: AWS protects the layers below your workloads: facilities, hardware, network, virtualization, and the software of managed services.

How it works: AWS data centers use layered physical controls (guards, cameras, mantraps, biometric access, and 24/7 staffing); hardware is racked in controlled cages; the global fiber backbone is private; the Nitro hypervisor isolates customer instances (it has no customer-accessible shell and is validated by third-party audits); managed-service software (the RDS engine, Lambda runtime, S3 storage layer) is patched by AWS.

Real use-case: When the SWEET32 or SonicWall CVEs hit the industry, on-premises teams spent weeks patching their virtualization stacks; AWS customers using RDS/Lambda read an AWS bulletin saying the managed layers were already handled — their only action was patching their own AMIs.

Gotchas & interview notes: AWS runs its layers through independent audits (SOC 1/2/3, ISO 27001, PCI DSS Level 1, FedRAMP), and you can download the reports from AWS Artifact. But you inherit compliance only for the AWS-MANAGED layers — your application layer is always yours to certify. If a pen-test report blames "the hypervisor," that is AWS's problem; 99% of the time it isn't the hypervisor.

Customer Responsibilities — "Security IN the Cloud"

Brief: You control everything you put ON the platform: data, identities, configuration, and — where applicable — operating systems.

How it works: The customer side has five classic pillars: customer data (classification, encryption choices, retention), identity and access management (who can do what), platform/config management (OS patching and firewall rules on EC2), network traffic protection (TLS, VPC design), and client/server-side encryption at rest.

Example: You run self-managed MySQL on EC2 — a critical kernel CVE is YOUR job to patch. Move that database to RDS — AWS now patches OS and MySQL engine; you still own security groups, the master password, IAM policies, and enabling encryption at rest.

Real use-case: The 2019 Capital One breach: a misconfigured WAF on the customer side let an attacker read IAM role credentials and use them against S3. Nothing AWS-managed failed — every failing control (WAF misconfiguration, over-privileged role, data access) sat on the customer side of the line. This incident is the industry's clearest lesson in the model.

Gotchas & interview notes: Encryption is ALWAYS the customer's choice to enable — AWS provides the mechanism (KMS, SSE), but nobody at AWS turns on S3 default bucket encryption or RDS encryption for you. Also remember pen-testing: you may security-test YOUR own resources, but you must request approval from AWS first (a form in the Security Center) — attacking AWS infrastructure itself is a violation.

Shared Responsibilities

Both contribute to: patch management (AWS patches the hypervisor, you patch the guest OS), security group configuration (AWS provides the feature, you write the rules), and awareness/training (AWS provides education; you train your staff). In incident reviews, shared items need a joint RCA — decide the owner BEFORE the incident.

Responsibility SHIFTS by Service Model

Brief: The more managed the service, the less you manage. This shift is the #1 discriminator between memorizing the model and understanding it.

How it works: Think of it as a stack of layers where the boundary line moves DOWN as services become more managed. With EC2, the line sits just above the OS. With RDS, it drops below the database engine. With Lambda, it drops below the runtime. What never moves: data, identity, and encryption CHOICES always stay with you.

Example: Same web app, three deployments — self-run MySQL on EC2 (you patch kernel + engine), RDS (AWS patches both; you patch nothing below your code), Lambda + DynamoDB (nothing below your code exists for you to patch).

Real use-case: A fintech's compliance matrix for "OS patch SLA: 14 days for criticals" applies to 200 EC2 instances; the same matrix line for RDS/Aurora is marked "AWS-managed — inherited control," shrinking their patch-audit scope by 60% and their scan scope in Inspector accordingly.

Gotchas & interview notes: Containers add nuance: with ECS/EKS you patch the host OS and your container image; with Fargate AWS manages the host and you own only the image. IAM permission boundaries and SCPs are YOUR tools — a permission boundary restricting a role is customer-side configuration even though the feature is AWS's. When an exam scenario says "we were breached through an unpatched X" — identify X's layer first, then name the owner.

Classic Exam Scenarios

• "Who patches the operating system on EC2?" → Customer
• "Who patches the hypervisor?" → AWS
• "Who enables S3 default encryption / decides KMS key rotation policy?" → Customer
• "Who is responsible for DynamoDB physical disk disposal?" → AWS
• "A Lambda function's runtime was patched overnight — who did it?" → AWS
• "Who decides which users can access a DynamoDB table?" → Customer (IAM)
• Post-mortems: write every failed control into one of two columns (AWS-side / customer-side) before proposing fixes — it prevents "let's file a ticket with AWS" for problems that are actually your security group.
• Compliance scoping: your audit scope is only the customer-side column. Mapping controls to the model early shrinks evidence collection dramatically (this is what AWS Audit Manager automates).
• Contract language: enterprise agreements explicitly reference the model; "AWS will secure the cloud, customer secures in the cloud" decides liability and, in breaches, who pays.
• Exception awareness: for the exam, encryption configuration is customer-side even when the feature is one checkbox. In reality — use S3 default bucket encryption + Bucket Key + KMS grants so the default is safe even when a developer forgets.

Senior-Level: Using the Model in the Real World

• "Who patches the operating system on EC2?" → Customer
• "Who patches the hypervisor?" → AWS
• "Who enables S3 default encryption / decides KMS key rotation policy?" → Customer
• "Who is responsible for DynamoDB physical disk disposal?" → AWS
• "A Lambda function's runtime was patched overnight — who did it?" → AWS
• "Who decides which users can access a DynamoDB table?" → Customer (IAM)
• Post-mortems: write every failed control into one of two columns (AWS-side / customer-side) before proposing fixes — it prevents "let's file a ticket with AWS" for problems that are actually your security group.
• Compliance scoping: your audit scope is only the customer-side column. Mapping controls to the model early shrinks evidence collection dramatically (this is what AWS Audit Manager automates).
• Contract language: enterprise agreements explicitly reference the model; "AWS will secure the cloud, customer secures in the cloud" decides liability and, in breaches, who pays.
• Exception awareness: for the exam, encryption configuration is customer-side even when the feature is one checkbox. In reality — use S3 default bucket encryption + Bucket Key + KMS grants so the default is safe even when a developer forgets.