1.7 The Shared Responsibility Model for Solutions Architects

Quick Answer: AWS secures OF the cloud (facilities, hardware, hypervisor, managed-service platforms). You secure IN the cloud (data, IAM, encryption choices, guest-OS patches on EC2, application code). The more managed the service, the less you manage — but data classification and encryption are always yours.

The Core Split

Think of one dividing line. AWS owns everything below the line; you own everything above it. Where that line falls depends entirely on the service type.

Responsibility Shifts by Service Type

IaaS — Amazon EC2 (maximum customer responsibility)

Managed — Amazon RDS, ElastiCache (shared)

Serverless — AWS Lambda, S3, DynamoDB (minimal customer responsibility)

On the Exam: "Who patches the OS on an EC2 instance?" → Customer. "Who patches the OS on an RDS instance?" → AWS. The single deciding factor is the service type (IaaS vs. managed vs. serverless).

Why This Matters to an Architect

The model is not trivia — it shapes design reviews. If you choose EC2, your design must include a patch strategy (Systems Manager Patch Manager), guest-level hardening, and OS-level logging, because AWS will not do any of that for you. Choose a managed or serverless equivalent and those duties disappear, which is often why the exam's "most operationally efficient" answer favors managed services. Regardless of service, the customer always owns data classification, encryption decisions, and account/identity configuration — a public S3 bucket or a leaked access key is never AWS's fault under this model.

Quick Duty-to-Owner Reference

Patch Management as a Design Decision

Because the customer owns OS patching on EC2, the exam expects you to name the AWS tool that operationalizes it: AWS Systems Manager Patch Manager scans and patches managed instances on a schedule using patch baselines and maintenance windows. This is the standard answer to "keep hundreds of EC2 instances patched with minimal operational effort." It does not apply to RDS or Lambda, where AWS already patches the platform — recognizing that boundary keeps you from proposing Patch Manager for a managed service.

Mapping the Model to Compliance

Auditors care which party owns each control. Under frameworks like PCI DSS or HIPAA, AWS provides attestations for the OF the cloud layers (delivered through AWS Artifact), while the customer must demonstrate controls for the IN the cloud layers — encryption configuration, IAM least privilege, logging, and network isolation. This is why "inherited controls" appear in audit conversations: the customer inherits AWS's data-center and hypervisor controls but must still prove their own configuration.

A HIPAA workload, for instance, requires the customer to sign a Business Associate Addendum, enable encryption, and restrict access, even though AWS secures the physical infrastructure.

Worked Scenario

A company runs a three-tier app: an ALB, EC2 web servers, an RDS MySQL database, and an S3 bucket for uploads. Who does what? AWS patches the RDS engine and OS, runs the ALB and S3 platforms, and secures all hardware. The customer patches the EC2 guest OS, writes the application code, configures every security group and bucket policy, enables encryption on EBS, RDS, and S3, sets up IAM roles for the instances, and classifies the uploaded data. Notice that across every tier the customer owns identity, network configuration, and encryption — the three duties that never shift to AWS regardless of service.

Exam framing: When a question says "most operationally efficient," the model nudges you toward more-managed services precisely because they move patching and availability duties to AWS — but never assume AWS owns your data, identities, or encryption choices.