AWS frames its entire security posture around one sentence: AWS is responsible for the security of the cloud, and the customer is responsible for security in the cloud. That distinction, published in AWS's own Shared Responsibility Model documentation, sounds simple until you realize it shifts depending on which of AWS's roughly 200+ services you're using. Run an EC2 instance and you own the guest OS, every security-group rule, and every IAM policy attached to it. Use S3 or DynamoDB and AWS operates the OS and platform for you — but a misconfigured bucket policy is still entirely your fault, not a platform failure. This is not a hypothetical distinction: publicly exposed S3 buckets have been the root cause behind data exposure incidents at organizations across finance, defense contracting, and consumer tech over the past decade, and in essentially every documented case, AWS's infrastructure worked exactly as designed — the bucket's access policy was simply set wrong by the account owner. This post walks through where the line actually falls across infrastructure, platform, and software service tiers, with concrete examples of the failure modes that live on each side of it.
What exactly does "security of the cloud" cover?
"Security of the cloud" is AWS's half of the model, and it covers everything a customer cannot see or touch: the physical data centers, the racks, the host hardware, the network infrastructure connecting AWS regions and availability zones, and the hypervisor layer that isolates one customer's virtual machine from another's. For managed services, AWS's scope extends further to include the guest operating system and the platform software itself. AWS documents this in its Shared Responsibility Model page and reiterates it in the AWS Well-Architected Framework's Security Pillar, where it's described as the foundation customers build on rather than something they configure. Physical security here means things like biometric access controls at data centers and environmental controls for power and cooling — none of it something a customer account can influence or misconfigure. If a hypervisor escape or a physical intrusion ever occurred, that would be an AWS-side failure. In over a decade of public AWS incident history, the overwhelming majority of customer-facing security failures have not come from this layer — they've come from the layer immediately above it, which is entirely the customer's job to configure correctly.
Where does responsibility sit for IaaS services like EC2?
Infrastructure-as-a-Service is where the customer's slice of responsibility is largest. On EC2, AWS secures the physical hosts and the hypervisor, but the customer owns the guest OS entirely — patching it, hardening it, and deciding when it reboots for updates. The customer also owns every security group and network ACL rule, every IAM role and policy attached to the instance, and any data or application code running on it. This is why "0.0.0.0/0" security group rules — inbound access open to the entire internet — remain one of the most common misconfigurations flagged by cloud security posture tools years after AWS made granular security groups the default. An unpatched guest OS on an EC2 instance, an EBS volume left unencrypted, or an overly permissive IAM role attached to an instance profile are all textbook customer-side failures; AWS's own infrastructure underneath none of them is compromised.
How does the line shift for managed services like S3 and RDS?
For managed, "abstracted" services — S3, DynamoDB, and RDS when using AWS-managed database engines — AWS operates the underlying infrastructure, the operating system, and the platform software itself, narrowing what the customer configures. On S3, the customer no longer patches an OS or manages a hypervisor; responsibility narrows to bucket policies, IAM permissions, encryption choices (server-side encryption with S3-managed keys versus AWS KMS-managed keys), and data classification. This narrower scope is exactly why misconfigured public S3 buckets are the model's most repeated case study: the platform layer AWS operates was never the problem, the resource-level access policy the customer set was. On RDS, AWS handles OS patching and database engine maintenance windows automatically, but the customer still owns network placement (is the instance in a public or private subnet), credential rotation, and which IAM database authentication method is enforced. The infrastructure risk shrinks; the configuration risk does not disappear, it just moves to a smaller and more specific set of settings.
What does the model look like for SaaS-style services?
For SaaS-style AWS offerings — services like WorkMail or Chime, or for that matter any third-party SaaS application running on top of AWS infrastructure — the provider's responsibility extends the furthest and the customer's shrinks to its narrowest point. The provider operates the application itself, not just the infrastructure and OS beneath it. What remains squarely on the customer is user access management (who has an account and what role they hold), data-sharing and sensitivity settings within the application, and endpoint-level configuration such as which devices are permitted to connect. This mirrors the pattern seen across SaaS security generally: identity governance — provisioning, deprovisioning, and permission scoping — is consistently the largest surviving customer obligation once infrastructure and platform operations are fully delegated to a provider.
Why do so many real-world cloud incidents fall on the customer side of the line?
Because the failure modes that recur most often — public S3 buckets, overly permissive IAM roles, open security groups, unpatched guest OSes, unencrypted EBS volumes — sit entirely within the "in the cloud" half of the model that AWS explicitly hands to the customer in its Risk and Compliance whitepaper and Well-Architected Security Pillar guidance. None of these require an AWS platform vulnerability to occur; they require a single misconfigured policy, role, or setting. This is also why cloud security posture management (CSPM) emerged as its own tooling category: the shared responsibility model doesn't just describe who's accountable, it predicts where security tooling investment needs to concentrate. AWS's own security services — IAM Access Analyzer, S3 Block Public Access (made a default in 2023), GuardDuty, and Config rules — exist specifically to help customers close the configuration gaps that sit on their side of a boundary AWS cannot cross on their behalf, no matter how well AWS secures the layers underneath.
Where does application-layer security fit once the infrastructure boundary is drawn?
Even after IAM policies, bucket permissions, and network rules are locked down, the "in the cloud" half of the model still includes the application code and dependencies running on that infrastructure — and that's a distinct problem from account configuration. A perfectly configured EC2 instance or ECS task can still ship a container image with a vulnerable transitive dependency or a hardcoded credential baked into a build artifact. That's the app-layer slice of customer responsibility — what's actually running inside your containers and dependency tree — and it's where SBOM-based tooling like Safeguard fits: generating a queryable inventory of every package and its known vulnerabilities so a new CVE disclosure doesn't require re-scanning your entire AWS footprint from scratch. It doesn't replace CSPM or IAM hygiene, but it closes the part of the shared responsibility boundary that lives inside the workload itself rather than in the account configuration around it.