The shared responsibility model is often the first slide in any AWS security training, and it’s usually summarised in one line: AWS is responsible for security of the cloud, you’re responsible for security in the cloud. That line is correct and not very useful on its own. The useful part is knowing where the boundary sits for each service you use, because it moves, and because nearly every well-known AWS security incident happened on the customer’s side of it.
The two halves
AWS’s side covers everything you can’t see or touch: the physical data centres and their guards, the hardware, the network between facilities, the virtualisation layer that isolates your instance from someone else’s, and the software that runs managed services. If a disk fails, a hypervisor has a vulnerability, or a data centre loses power, that’s AWS’s job to handle, and you couldn’t do anything about it if you wanted to.
Your side covers everything you configure or put in: who can access your account and with what permissions, your network rules, your data and whether it’s encrypted, the operating systems and code you run, and how all of it is configured. AWS gives you the tools (IAM, security groups, KMS, CloudTrail) but doesn’t decide how you use them. An S3 bucket made public by a bucket policy is working exactly as configured.
Some controls are shared, where each party handles its own layer. Patching is the standard example: AWS patches its infrastructure and the managed parts of services, you patch your guest operating systems and application dependencies. Training is another: AWS trains its staff, you train yours.
How the line moves between services
The model looks different depending on how much of the stack the service manages. It’s easiest to see side by side:
| Concern | EC2 | RDS | Lambda | S3 |
|---|---|---|---|---|
| Physical hosts, hypervisor | AWS | AWS | AWS | AWS |
| Operating system patches | You | AWS | AWS | AWS |
| Database engine or runtime patches | You | AWS applies them; you choose versions and maintenance windows | AWS for managed runtimes; you if you use a container image | n/a |
| Network access (security groups, public access) | You | You | You (VPC config, function URL auth) | You (bucket policy, Block Public Access) |
| Identity and permissions | You | You (IAM and database users) | You (execution role, resource policy) | You |
| Encryption choices and keys | You | You | You | You (SSE-S3 is now default; KMS keys and policies are yours) |
| Application code and dependencies | You | n/a | You | n/a |
| Backups and retention | You | AWS runs them; you set retention and test restores | n/a | You (versioning, replication) |
Read down a column and you can see the trend: moving from EC2 to Lambda takes the OS and runtime off your plate. Read across the bottom rows and you see what never moves: identity, network exposure, encryption decisions and data protection are yours on every service.
A few details in that table come up in interviews:
- RDS patching. AWS applies OS and engine patches, but in a maintenance window you choose, and major version upgrades are your call. Running an end-of-life engine version is your risk, and AWS eventually charges for extended support on old versions.
- Lambda with container images. If you package a function as a container image, you own the base image and its OS packages. Managed runtimes are patched by AWS.
- Lambda dependencies. AWS patches the runtime, but the npm or pip packages in your deployment package are yours. A vulnerable library in a Lambda function is exactly as exploitable as one on EC2.
Walking through an incident
Here’s a realistic chain of events, with the owner of each link. A company runs a web app on EC2 behind a load balancer, with uploads stored in S3 and data in RDS.
- An old version of a logging library on the EC2 instances has a remote code execution vulnerability. The instances’ guest OS and application dependencies are customer-managed. Owner: the customer. AWS doesn’t scan or patch software inside your instances (though Amazon Inspector, which you can turn on, would have flagged it).
- The attacker gets a shell and reads the instance metadata service to get the instance role’s temporary credentials. IMDS behaving as designed is AWS’s side. Whether the instance requires IMDSv2 and what the role is permitted to do is the customer’s side. The role had
s3:*on*, a customer decision. - With those credentials, the attacker lists every bucket and downloads customer uploads. S3 enforced the policies it was given. The permissions were the customer’s.
- The same role could call
rds:ModifyDBSnapshotAttributeand share a database snapshot with an external account. Again: permissions as configured. - Nobody noticed for three weeks. CloudTrail was recording, but no one was alerting on unusual API calls. GuardDuty, which detects things like credentials used from unusual locations, wasn’t enabled. Detection and response are the customer’s side.
Every step ran on AWS infrastructure that worked correctly. The fixes are all on the customer side: patch dependencies, require IMDSv2, scope roles to what the app needs (s3:GetObject on one bucket’s objects), restrict snapshot sharing with an SCP, and turn on GuardDuty and alerts. That pattern, where the platform holds and the configuration fails, matches most publicly reported cloud breaches.
Compliance: inheriting controls, not certifications
AWS publishes audit reports (SOC 2, ISO 27001, PCI DSS attestations and others) through AWS Artifact. When your auditor asks about physical security of the data centre, you point to those reports; you inherit those controls.
What you can’t inherit is your half. Running on a PCI-compliant service doesn’t make your application PCI-compliant. An auditor will still ask how you restrict access to cardholder data, how you log access, how you manage keys and how you patch your software. A common mistake in interviews (and in real compliance projects) is saying “we’re on AWS, so we’re compliant”.
Tools that help you show your half: AWS Config rules and conformance packs to check configurations continuously, Security Hub to aggregate findings against standards like the CIS AWS Foundations Benchmark, and CloudTrail for an audit log of API activity.
Interview practice: whose problem is the public snapshot?
A security researcher reports that one of your RDS snapshots is publicly shared and contains customer data. A colleague says, “RDS is a managed service, so this is on AWS.” Respond, and describe what you’d do now and to prevent it.
Answer
It isn’t AWS’s responsibility. RDS is managed in the sense that AWS runs the database engine, the OS, hardware and automated backups. Who a snapshot is shared with is a configuration setting controlled through the API by principals in our account. Someone in our account, or something with our credentials, marked it public. AWS enforced exactly what was configured.
Right now: make the snapshot private (remove all from its restore attribute), then check CloudTrail for the ModifyDBSnapshotAttribute call to see who did it and when, and whether any external account copied or restored it in the meantime. Treat it as a data exposure incident, which may have notification obligations depending on the data and the jurisdiction. Rotate database credentials if the snapshot contained them.
To prevent it: an SCP that denies rds:ModifyDBSnapshotAttribute (and its cluster equivalent) when it would add all as a value, an AWS Config rule that flags public snapshots, and encryption with a customer managed KMS key, since an encrypted snapshot is useless to another account unless our key policy also grants it access. The point I’d make out loud: “managed” moves operational work to AWS, but sharing, permissions and data exposure stay with us on every service.