The clearest way to hold it is as a stack with a cut through it, where the cut sits at a different height per service. Below the cut AWS operates and patches the layer; above it, the customer does. EC2 puts the cut just under the guest operating system; a managed database puts it above the engine; a function runtime puts it directly under the function code.
The trap is reading “AWS patches it” as “nothing is required of us”. A managed database with a patched version available and the old one still running is exposed, and the exposure belongs to whoever chose not to schedule the upgrade. The same holds for a function runtime past its deprecation date, which AWS no longer patches. Where the cut sits can also be a setting. Lambda applies runtime updates automatically by default, and a function switched to manual runtime management stops receiving them until someone moves it back.
Three responsibilities never move: the data, who can reach it, and how it is classified. The customer’s list gets shorter as more of the stack becomes managed, and it never empties. One advisory across five services shows the same line sitting at five different heights across one estate.
Flash card
AWS shared responsibility model: AWS is responsible for security **of** the cloud (hardware, facilities, and the software AWS runs); the customer is responsible for security **in** the cloud (their data, their identities, their configuration and whatever they install).
- AWS always holds: physical data centre security, hardware, the host operating system and virtualisation layer, the network infrastructure, and the destruction of decommissioned storage media.
- The customer always holds: their data, who can access it, how it is classified, the encryption choices, and the network and firewall configuration they set.
- The line moves with the service. On EC2 the customer patches the guest operating system. On RDS and Lambda, AWS patches the engine, the runtime and the OS beneath them. On Fargate, AWS provisions and patches the infrastructure; the container image stays the customer’s.
- Producing a patch and applying it are different responsibilities. AWS publishes a fixed RDS engine version and the customer schedules the maintenance window that takes it, though RDS applies a mandatory update itself once its apply date passes.
- Software bought through AWS Marketplace and deployed into the customer’s own account, an AMI or a container image, is the customer’s to operate and update. Buying through a marketplace changes procurement, not responsibility.
- IAM Identity Center, IAM policies and resource policies are all customer-side controls: AWS provides the capability, the customer decides who gets what.
- AWS Artifact supplies AWS’s own compliance reports (SOC, ISO, PCI DSS attestations) for the part of the line the customer cannot inspect. The customer’s own evidence comes from their records in AWS Config and CloudTrail; AWS Audit Manager covered that ground, but it is in maintenance mode and closed to new accounts since 30 April 2026.
Pick it when
Pick it when a scenario asks who patches, who configures, who is accountable for a control, or what a customer must still do after adopting a managed service.
It's the wrong answer when
It settles no service choice, and it is not a compliance framework. It is the wrong answer for which standard an estate is measured against, which is AWS Security Hub CSPM, and for where AWS’s certifications live, which is AWS Artifact.