AWS Shared Responsibility Model: What Changes With the Service? · AWS Cloud Practitioner

Start with an obligation, not a slogan

A useful responsibility decision has three parts: the service actually selected, the layer affected, and the task being assigned. “AWS secures the cloud” is a starting distinction, but it is too broad to decide whether a particular team should patch an operating system, revise database permissions, or rebuild a container. Name the specific task first. Two teams can both be right about different layers while believing they disagree about the whole system.

AWS operates underlying infrastructure, including physical facilities and the infrastructure hosting its services. Customer obligations vary with service selection and with the organization’s use case. A change in service abstraction can move an operating duty without moving a business decision. The correct output is therefore an obligation ledger, not a single label saying that an entire project is either customer-operated or AWS-operated.

Read the ledger with its assumptions

For customer-managed EC2, keep guest-operating-system updates and installed application software with the customer. The guest OS is inside the instance the customer runs; it is distinct from AWS host infrastructure. Buying virtual compute capacity does not make those two operating-system layers the same. If a notice names the guest OS, routing it to physical-facility maintenance misses the affected component.

For RDS, AWS handles common database administration operations, including backups and software patching. This changes the operations ledger. It does not assign query tuning to AWS: query performance depends on the customer’s schema, workload, queries, and data. Nor does it decide which staff should be allowed to read a sensitive table. The customer still applies security controls matching data sensitivity, organizational requirements, and applicable rules.

For the diagram’s Lambda row, assume a Lambda Event Function using an AWS managed runtime with Auto updates. AWS manages underlying execution infrastructure and publishes managed-runtime security updates applied according to that mode. Data, identity/access, workload configuration, and code-security decisions remain customer concerns. Change the deployment to a container image and the update row must change: the customer rebuilds and redeploys that image. The label Lambda alone is insufficient to settle every update question.

Worked dispute: a historical society’s catalog

Fictional case: a historical society is considering three ways to run separate parts of its catalog workflow. One part remains an application on EC2; one uses an RDS database; a new ingest validator uses a managed Lambda Event Function with Auto runtime updates. Its operations coordinator assigns all update tasks to AWS, while a second coordinator insists the society must maintain all physical hosts. Neither rule respects the component boundaries.

Begin with the EC2 application. A guest-OS update belongs on the society’s checklist, while physical host maintenance does not. For the RDS component, common database patching is managed, but the society still owns query tuning and its decision about curators’ database access. For the Event Function, the stated runtime assumption supports the managed update row; the society still secures its validation logic and chooses what records and services that code can access.

Now check a proposed change: the society packages the validator as its own container image. Keep the customer data/access rows and AWS underlying-infrastructure row. Replace the simplified runtime-update assumption with customer image rebuild/redeployment. This one changed fact alters one operating obligation; it does not make the society responsible for replacing AWS physical servers. The completed ledger resolves the two coordinators’ overbroad assignments without claiming that either party owns everything.

Why retained decisions matter

Consider a counterexample: an RDS database receives the expected managed software updates, but an employee group still has broader access than the society intends. Infrastructure maintenance can be working correctly while customer authorization is wrong. Asking AWS to choose the society’s legitimate readers would require unstated business knowledge. The practical teaching question is whose requirement determines the permission, not whether the service is generally described as managed.

A similar boundary applies to a function that accepts a catalog record. A maintained runtime does not establish that the record meets the society’s business rules. Application logic, allowed data use, and permissions need their own review. Conversely, finding a customer-side validation defect does not prove the customer should take over physical infrastructure. Diagnose the affected layer before widening the action or assigning blame.

Apply the model before reading the check basis

Check 1: a managed Event Function accepts a donation amount that violates a fictional organization’s own rules. A colleague says that managed runtime patching proves the donation must be legitimate. Explain the category error. Check basis: patching addresses software maintenance at a stated layer; legitimacy is an application/business validation question. Customer code and data decisions remain. An answer that only repeats “shared responsibility” without identifying these two tasks is incomplete.

Check 2: a ticket says “update the Lambda runtime,” but gives neither deployment package nor runtime-update mode. Can you assign all update work immediately? Check basis: request those missing details. The managed-runtime Auto assumption supports a different workflow from a customer-maintained container image. Do not quietly substitute the easiest assumption. Review the responsibility diagram, then use lessons aws-clf-skill-03 and aws-clf-skill-04 and formal tasks aws-clf-q-009–012 for additional cases. This ledger supports foundational reasoning, not a complete production security or compliance review.