An AWS breach is almost never a failure of AWS itself — it is a customer-side misconfiguration: a public S3 bucket, a leaked access key, an over-permissioned IAM role, or an SSRF flaw that reaches the instance metadata service. Under the AWS shared responsibility model, Amazon secures the cloud infrastructure and you secure what you put in it. Nearly every high-profile AWS security breach on record landed squarely on the customer's side of that line, which is good news: the controls that prevent them are things you fully control.
Understanding how the real incidents worked is more useful than any checklist, because the same handful of root causes repeat. Get those closed and you have addressed the mechanisms behind the overwhelming majority of AWS breaches.
The shared responsibility line, and which side breaks
AWS states it plainly: they are responsible for security of the cloud — the physical data centers, the hypervisor, the managed service internals. You are responsible for security in the cloud — your IAM policies, your S3 bucket permissions, your security groups, your application code. When people say "we got breached on AWS," they almost always mean a control on their side of the line was left open.
This matters because it tells you where to spend effort. Auditing AWS's data-center security is not your job and not your risk. Auditing your own IAM roles, storage permissions, and metadata exposure is both.
The Capital One breach: an SSRF master class
The 2019 Capital One breach is the canonical AWS breach case study, and worth understanding in detail because its mechanism keeps recurring. The attacker, a former AWS engineer, exploited a server-side request forgery (SSRF) vulnerability in a misconfigured web application firewall. SSRF let them make the server issue requests on their behalf — including a request to the EC2 instance metadata service at 169.254.169.254.
That metadata endpoint hands out temporary IAM credentials for the role attached to the instance. Those credentials had broad S3 permissions, so the attacker used them to list and download data from S3 buckets containing roughly 106 million credit card application records. Capital One later faced an $80 million regulatory penalty and a $190 million class-action settlement.
Two customer-side failures chained together: an SSRF bug in the application, and an IAM role with far more S3 access than the workload needed. Either one closed would have blunted the attack. The industry response was IMDSv2, which requires a session token obtained via a PUT request that SSRF typically cannot perform.
The five root causes behind most AWS breaches
Strip away the branding and nearly every AWS breach reduces to one of these:
- Public S3 buckets. A bucket policy or ACL set to public, or "authenticated users" misread as "your users." Sensitive data becomes world-readable.
- Leaked long-lived credentials. An
AKIA...access key committed to a public GitHub repo, embedded in a mobile app, or pasted into a config file. Automated scanners find these within minutes of exposure. - Over-privileged IAM. Roles and users granted
*:*or broad service wildcards "to make it work." When any one credential leaks, the blast radius is the whole account. - SSRF to metadata. An application flaw that lets an attacker reach the instance metadata service and steal role credentials, as in Capital One.
- Exposed management surfaces. Security groups left open to
0.0.0.0/0on database ports, admin panels, or RDP/SSH.
Controls that close them
Start with metadata. Enforce IMDSv2 across every instance and require it in your launch templates so no new instance can fall back to the vulnerable v1:
# require IMDSv2 (token-backed) on an existing instance
aws ec2 modify-instance-metadata-options \
--instance-id i-0123456789abcdef0 \
--http-tokens required \
--http-endpoint enabled
Block public S3 at the account level so no individual bucket can be made public by accident:
aws s3control put-public-access-block \
--account-id 123456789012 \
--public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
For credentials, prefer IAM roles over long-lived access keys everywhere you can, and scan your repositories for committed secrets before they ever reach AWS. A leaked key in git is one of the fastest paths to an AWS breach, and secret scanning in CI catches it at commit time. For IAM, run Access Analyzer and pare roles down to least privilege using the access-advisor data on what each role actually uses.
Detecting a breach in progress
Prevention is not enough on its own; you need to see the anomaly. Enable CloudTrail in every region and route it to a location the account's own credentials cannot delete. Turn on GuardDuty, which specifically flags patterns like instance credentials being used from an external IP — the exact signal the Capital One attack would have thrown. Alert on unusual S3 ListBucket and GetObject volume from a single role. Beyond native cloud data, keeping an inventory of what code and dependencies run on those instances helps too; an SCA tool can surface a vulnerable library that becomes the SSRF foothold, and continuing your security education through resources like our academy keeps the team current on new attack patterns.
FAQ
Is an AWS breach usually Amazon's fault?
No. Under the shared responsibility model AWS secures the underlying infrastructure while you secure your configuration, IAM, and data. The overwhelming majority of AWS breaches trace to customer-side misconfiguration such as public buckets, leaked keys, or over-privileged roles.
What was the biggest cause of the Capital One AWS breach?
Two chained failures: an SSRF vulnerability that reached the instance metadata service, and an over-privileged IAM role with broad S3 access. The stolen role credentials were used to download about 106 million records. IMDSv2 and least-privilege IAM would each have disrupted it.
How do I prevent an AWS security breach from leaked keys?
Avoid long-lived access keys — use IAM roles and short-lived credentials — and scan code repositories for secrets in CI so a committed AKIA key is caught before it reaches a public repo. Rotate and disable any key that is exposed.
What is IMDSv2 and why does it matter?
IMDSv2 is the token-required version of the EC2 instance metadata service. It forces a PUT request to obtain a session token before credentials are returned, which most SSRF attacks cannot perform. Enforcing http-tokens required blocks the metadata-theft path used in real AWS breaches.