When a headline says "AWS hacked," it almost never means Amazon's cloud infrastructure was breached; it means an AWS customer misconfigured something they owned and an attacker walked through the gap. So has AWS ever been hacked? The core AWS platform, the hypervisors, the physical data centers, the control plane, has not suffered a publicly confirmed compromise. What happens over and over is that organizations running on AWS leave a storage bucket public, a credential exposed, or a permission too broad, and lose data as a result. Those are customer breaches on AWS, not breaches of AWS.
That distinction is not a technicality. It determines who is responsible, what you can control, and where you should spend your security effort. This post explains the model, walks through what actually goes wrong, and covers the controls that matter.
The shared responsibility model in one paragraph
AWS operates on a shared responsibility model: AWS is responsible for security of the cloud, and you are responsible for security in the cloud. AWS secures the infrastructure, the hardware, the networking backbone, the managed-service internals. You secure your data, your identity and access configuration, your network rules, your operating systems and application code. The line moves depending on how managed the service is, but the principle holds: the provider hardens the platform, and the customer configures their slice of it. Most incidents attributed to "AWS being hacked" fall entirely on the customer side of that line.
The Capital One breach: the textbook case
The most-cited example is Capital One. In 2019, Capital One disclosed that an attacker had accessed the personal information of roughly 100 million people in the United States and about 6 million in Canada, one of the largest financial-sector breaches on record.
The mechanism is instructive because nothing about AWS itself failed. The attacker exploited a server-side request forgery (SSRF) weakness in a misconfigured web application firewall that Capital One ran. That SSRF was used to reach the cloud instance metadata service and retrieve the credentials of an IAM role attached to the server. Those credentials had broad permissions, which let the attacker list and read data from storage the role could reach. The attacker was a former cloud engineer who was later convicted.
Every failure in that chain was a customer-owned configuration: the firewall rules, the overly permissive IAM role, and the exposure of the metadata endpoint. AWS later made the instance metadata service v2 (IMDSv2) the default-recommended, session-oriented design precisely to make this class of SSRF-to-credential-theft attack much harder. But the lesson stands. The platform was not hacked; a customer's setup was.
What actually goes wrong on AWS
The recurring failure modes are boringly consistent, which is good news because they are all preventable:
- Public storage buckets. An S3 bucket set to public, or an over-broad bucket policy, exposes data to anyone who finds the URL. This is the single most common cause of "AWS data leak" stories.
- Leaked long-lived credentials. Access keys committed to a public Git repo, embedded in a mobile app, or left in a CI log get scraped within minutes and used to spin up resources or exfiltrate data.
- Over-permissive IAM. Roles and users granted
*permissions "to make it work" become the blast radius when any one component is compromised. - Exposed services with weak or no auth. Databases, dashboards, and management endpoints reachable from the public internet without authentication.
- Misconfigured network rules. Security groups opened to
0.0.0.0/0on sensitive ports.
Industry analyses consistently attribute the large majority of cloud security incidents to misconfiguration rather than provider failure. The attacker's job is often just to find the one setting you got wrong.
The controls that prevent customer breaches
Because the failures are predictable, so are the defenses. In rough priority order:
Lock down identity. Enforce least-privilege IAM, require MFA, and prefer short-lived role credentials over long-lived access keys. Rotate anything long-lived and scan your code and history for exposed secrets.
Close public exposure by default. Turn on S3 Block Public Access at the account level, default security groups to deny, and audit anything reachable from the internet.
Use IMDSv2 and hop-limit restrictions so an SSRF cannot trivially harvest instance credentials, the exact gap behind Capital One.
Monitor continuously. Enable CloudTrail, GuardDuty, and configuration-drift detection so a dangerous change is caught quickly rather than discovered in a breach report.
Shift the checks left. Most misconfigurations are introduced in infrastructure-as-code before anything is deployed. Scanning Terraform, CloudFormation, and container definitions in the pipeline catches a public bucket or a wildcard IAM policy before it ever reaches production. The DAST product covers the running-application side of that testing, and the academy has a cloud-hardening track that maps these controls to the shared responsibility model.
So, has AWS ever been hacked?
The accurate answer to "has AWS ever been hacked" is: AWS the platform has not suffered a confirmed infrastructure breach, but organizations running on AWS are breached routinely through mistakes on their side of the shared responsibility line. Reframing the question that way is the whole point. You cannot patch Amazon's data centers, and you do not need to. You can, and must, fix your buckets, your IAM, and your network rules. That is where essentially all of the risk you control actually lives.
FAQ
Has AWS itself ever been hacked?
There is no publicly confirmed breach of AWS's core infrastructure, hypervisors, or physical data centers. The incidents commonly described as "AWS hacked" are breaches of AWS customers caused by their own misconfigurations, exposed credentials, or over-broad permissions, not compromises of the AWS platform.
What was the Capital One AWS breach?
In 2019, Capital One disclosed a breach affecting roughly 100 million people in the US and about 6 million in Canada. An attacker exploited an SSRF flaw in a misconfigured web application firewall to obtain IAM role credentials from the instance metadata service and read data. Every failure was a customer configuration, not an AWS platform flaw.
Who is responsible when data on AWS is breached?
Under the shared responsibility model, AWS secures the cloud infrastructure and the customer secures their data, identity configuration, and network rules. Most breaches result from customer-side misconfiguration, so responsibility for those typically sits with the customer, not AWS.
How do I prevent an AWS breach?
Enforce least-privilege IAM with MFA and short-lived credentials, block public access to storage by default, use IMDSv2, monitor with CloudTrail and GuardDuty, and scan infrastructure-as-code in your pipeline so misconfigurations are caught before deployment.