Nearly every well-documented AWS security breach in the past decade traces back to the same handful of root causes: a publicly accessible S3 bucket that shouldn't have been, an IAM role with far more permission than the workload needed, or a credential leaked into a place an attacker could find it. AWS's own infrastructure has a strong security track record; the pattern across real incidents is customer-side misconfiguration within the shared-responsibility model, not a break in AWS's underlying platform.
What did the Capital One breach actually reveal about IAM misconfiguration?
The 2019 Capital One breach exposed roughly 106 million customer records after an attacker exploited a server-side request forgery vulnerability in a misconfigured web application firewall to reach the EC2 instance metadata service, then used the overprivileged IAM role credentials available there to access S3 buckets far beyond what that specific application needed. The lesson wasn't about a novel AWS vulnerability — it was that the IAM role attached to the compromised instance had broad read access to storage well outside its actual job, which turned one SSRF bug into a mass data exposure. Scoping IAM roles tightly to the specific resources a workload needs, rather than convenience-driven broad permissions, would have contained the blast radius significantly.
Why do public S3 buckets keep causing AWS security breaches?
S3 buckets default to private, but a long history of incidents — exposed voter records, leaked government contractor files, unsecured backups from major companies — comes down to someone explicitly changing bucket or object permissions to public, often for a legitimate short-term reason (sharing a file, testing an integration) that never gets reverted. AWS has added guardrails over time, including account-level "Block Public Access" settings that override individual bucket policies, but they have to be turned on and left on. Continuous configuration scanning that flags any bucket policy change toward public access, rather than a one-time audit, is what actually catches this before data leaks rather than after.
How do leaked AWS credentials lead to breaches, and where do they leak from?
Hardcoded access keys committed to a public GitHub repository are one of the most common and fastest-exploited leak vectors — automated scanners run constantly against public commits looking for AWS key patterns, and a leaked key with meaningful permissions can be found and abused within minutes of a push. Other common leak points include credentials baked into container images pushed to a public registry, keys embedded in mobile app binaries, and environment variables exposed through a misconfigured debug endpoint. The structural fix is avoiding long-lived static credentials in code entirely — using IAM roles for compute, short-lived STS tokens, and secrets managers instead — so there's no static key sitting in a repository to leak in the first place.
What's the actual shared-responsibility line that these breaches fall on?
AWS is responsible for the security of the cloud — physical data centers, hypervisor isolation, the durability of the underlying storage and network fabric. The customer is responsible for security in the cloud — IAM policy, S3 bucket permissions, security group rules, patching the software running on EC2 instances, and encryption configuration. Nearly every major publicized AWS security breach falls on the customer side of that line, which is exactly why it doesn't show up as an "AWS vulnerability" in any disclosure database — it shows up as a postmortem about a specific customer's configuration.
What should a team actually do differently after reading these postmortems?
Three practices address most of the pattern directly: enable account-level S3 Block Public Access and alert on any change to it, scope IAM roles to least privilege with regular access reviews rather than broad managed policies applied for convenience, and eliminate static credentials in favor of role-based access wherever compute runs. Continuous cloud configuration scanning catches drift from these baselines as it happens rather than at the next scheduled audit, which matters because most of these breaches involved a misconfiguration that existed for weeks or months before being found — by an attacker, a researcher, or occasionally a customer's own internal audit.
FAQ
Was the Capital One breach caused by an AWS vulnerability?
No — it was caused by a misconfigured customer-side web application firewall combined with an overprivileged IAM role attached to the compromised EC2 instance. AWS's infrastructure itself was not the vulnerable component.
How common are S3-related breaches compared to other AWS security breach causes?
Publicly exposed S3 buckets remain one of the most frequently reported categories in aggregated cloud breach data, largely because the failure mode (misconfigured or reverted-to-public bucket policy) is simple to create and easy for automated scanners — both defensive and malicious — to find.
Does using AWS make a company automatically compliant with SOC 2 or similar frameworks?
No — AWS's own SOC 2 report covers the infrastructure it operates, but a customer still needs to configure and evidence their own controls (IAM, logging, encryption, access reviews) on top of that infrastructure to meet SOC 2 requirements themselves.
What's the fastest way to check for IAM overprivilege in an existing AWS account?
AWS IAM Access Analyzer and the "last accessed" data on IAM policies both surface permissions that are granted but never actually used, which is usually the fastest starting point for tightening a role before an incident forces the review.