If your S3 bucket is public, that's on you, not AWS. That single fact trips up more engineering teams than almost any other cloud security concept, and it has caused some of the most expensive breaches in recent history. The AWS shared responsibility model splits security duties into two buckets: AWS secures "the cloud" (physical data centers, hypervisors, network infrastructure, and the managed portions of its services), while the customer secures what they put "in the cloud" (data, identity and access management, operating system patches on unmanaged compute, network controls, and application code). The split isn't fixed -- it moves depending on whether you're running raw EC2 instances, a managed database like RDS, or a fully serverless function on Lambda. Misreading where the line falls is the single most common root cause of cloud data breaches, and it's entirely preventable with the right controls.
What Is the AWS Shared Responsibility Model?
The AWS shared responsibility model is a division of security duties in which AWS is responsible for "security of the cloud" and the customer is responsible for "security in the cloud." AWS has published this framework since at least 2011, and it underpins every compliance attestation AWS holds, including SOC 2, ISO 27001, and FedRAMP. On its side, AWS secures the physical facilities, the hardware and host operating systems, the virtualization layer, and the global network AWS-managed services run on. On the customer side, you own guest OS configuration (for unmanaged compute), firewall and security group rules, identity and access management, encryption of data at rest and in transit, and the security of any code you deploy. AWS states this plainly in its own documentation: the customer's job is "correct configuration," not just "usage."
Who Is Responsible for What Under the Model?
Responsibility is split by asset category, not by service name, so the same rule applies whether you're looking at IAM, networking, or data. AWS owns the global infrastructure: 34 geographic regions and 108 Availability Zones as of 2024, the physical security of its data centers, and the durability guarantees behind services like S3 (11 nines of durability). The customer owns four things regardless of which AWS service they use: (1) IAM policies and credential hygiene, (2) network configuration such as security groups, NACLs, and VPC design, (3) data classification and encryption settings, and (4) client-side and application-layer security, including the code they push. AWS will never rotate your IAM access keys for you, and it will not decide whether your S3 bucket policy should allow public read access -- both are 100% customer-owned decisions, and both have caused real breaches when set incorrectly.
How Does Responsibility Shift Between EC2, RDS, and Lambda?
Responsibility shifts toward AWS as you move up the stack from infrastructure-as-a-service to platform- and function-as-a-service, but it never disappears entirely from the customer side. On EC2 (IaaS), you patch the guest OS, manage the kernel, configure host-based firewalls, and secure anything you install -- AWS only guarantees the hypervisor and physical hardware underneath. On RDS (a managed PaaS database), AWS handles OS patching, database engine patching, and automated backups, but you still own network access rules, master credential rotation, encryption key management via KMS, and IAM database authentication. On Lambda (FaaS), AWS manages the entire runtime, OS, and scaling infrastructure, leaving you responsible for exactly two things: the code you write and the IAM execution role permissions you attach to it -- over-permissioned Lambda roles are one of the most common serverless misconfigurations found in AWS environments today.
What Real-World Breaches Trace Back to Shared Responsibility Confusion?
Two of the most-cited cloud breaches in the last decade both trace directly to customer-side misconfiguration, not an AWS platform failure. In June 2017, a third-party vendor working with Verizon misconfigured an S3 bucket, leaving roughly 14 million customer records -- including PINs and account details -- publicly accessible for six days before it was secured. In July 2019, Paige Thompson exploited a misconfigured web application firewall running on an EC2 instance at Capital One to perform a server-side request forgery (SSRF) attack, retrieve temporary IAM credentials from the instance metadata service, and pull data from more than 700 S3 buckets, exposing information on 106 million people. Capital One paid an $80 million penalty to the Office of the Comptroller of the Currency in August 2020 and a further $190 million to settle a class action in 2022. In both cases, AWS's underlying infrastructure was never at fault -- the WAF rule, the S3 bucket policy, and the IAM permissions were entirely the customer's responsibility to configure correctly.
How Does the Model Apply to Containers and Kubernetes on EKS?
On Amazon EKS, AWS manages the Kubernetes control plane -- the API server, etcd, and scheduler -- while the customer remains fully responsible for worker nodes, container images, and workload configuration. AWS patches control plane CVEs and guarantees control plane uptime under an SLA, but a CVE like CVE-2020-8554 (a Kubernetes man-in-the-middle vulnerability affecting shared clusters) still required customers to patch or mitigate it themselves at the node and admission-controller level, because worker nodes are customer-managed compute. Customers on EKS also own IAM Roles for Service Accounts (IRSA) configuration, network policies, pod security standards, and the provenance of every base image pulled into a cluster. A cluster with a hardened control plane and an unpatched, internet-facing worker node is still a fully exploitable target -- the shared responsibility line runs straight through the middle of your Kubernetes stack, not around it.
How Safeguard Helps
Safeguard maps the customer side of the shared responsibility model directly onto your actual attack surface, rather than leaving teams to guess which AWS misconfigurations matter most. Reachability analysis determines whether a vulnerable package, exposed IAM permission, or risky container base image is actually exploitable in a running workload, cutting through the noise that comes from treating every finding as equally urgent. Griffin AI, Safeguard's reasoning engine, correlates vulnerability data, SBOM contents, and cloud configuration to explain why a given finding is or isn't a real risk in plain language. Safeguard generates and ingests SBOMs across your AWS build pipelines so you always know what's running on EC2, in Lambda, or inside your EKS clusters, and when a fix is available, Safeguard opens an auto-fix pull request so the customer side of the shared responsibility model gets remediated without a manual ticket queue.