Amazon Web Services powers a remarkable proportion of the modern internet, which makes it both an obvious target and a common source of large-scale leaks. The pattern in the news rarely involves clever zero-days. It usually involves an S3 bucket left wide open, an IAM policy that grants more than anyone intended, or a forgotten EC2 instance with credentials baked into a script. Cloud breaches, on the whole, are misconfiguration breaches.

S3 Buckets Still Spill Data

S3 has had block public access available by default for years, yet exposed buckets still appear in public scans every week. The culprit is usually a developer who flipped the setting to test something quickly, then never flipped it back. Worse, even buckets that are technically private can leak through pre-signed URLs with overly generous expiries, or through bucket policies that inadvertently trust an entire AWS account when they meant to trust a single role. Test what your buckets actually allow rather than what you intended them to allow.

IAM Is Where Most Breaches Begin

Identity and access management in AWS is famously powerful and famously easy to get wrong. Wildcards in resource ARNs, policies attached to roles that nobody reviews, and trust relationships that allow assumption from broader principals than necessary all combine into something an attacker can exploit. Once an intruder gains a foothold through a compromised key, they pivot through these connections at speed. Solid AWS penetration testing services examine the entire IAM graph rather than spot-checking the obvious accounts.

Expert Commentary

Name: William Fieldhouse

Title: Director of Aardwolf Security Ltd

Comments: The most damaging finding I tend to surface in AWS engagements is not a single misconfiguration but a chain of small ones. A developer with broader rights than needed, attached to a role that other roles can assume, attached to a Lambda that runs on data nobody audits. Each link looks innocuous in isolation.

Forgotten Resources Hold Forgotten Risk

Article image

AWS makes it easy to spin up resources, and equally easy to forget you ever did. EBS volumes from decommissioned instances, Lambda functions that nobody owns, ancient CloudFormation stacks with hard-coded credentials, and EC2 AMIs shared too broadly all pile up over time. Periodic vulnerability scanning services that map your AWS estate and flag drift help keep this in check. Most organisations are stunned by how much shadow infrastructure shows up on the first scan.

Secrets Management Goes Wrong Quietly

Secrets baked into Lambda environment variables, shipped in container images, or committed to public repositories continue to drive incidents. AWS Secrets Manager and Parameter Store both exist for a reason. Use them. Rotate keys regularly, scope access tightly, and run automated checks against your repositories so a stray AKIA prefix triggers an alert before it triggers a bill. The clean-up after a leaked key is always more painful than the discipline that prevents the leak.

Building Resilience Properly

Resilience in AWS is not a feature you buy. It is the result of careful design, regular review, and a willingness to test your assumptions. Use multiple accounts to separate production from development, apply service control policies at the organisation level, log everything to a separate logging account, and run regular reviews against the AWS Well-Architected pillars. The investment seems heavy until something goes wrong, at which point you wish you had started sooner.