AWS Just Killed Bucketsquatting After a Decade of Warnings — Here Is What Changed and Why You Should Rename Every Bucket You Own

I got the notification at 6:47 AM on a Thursday, which is precisely when nobody wants to deal with a security advisory. My colleague Derek — who runs infrastructure for a mid-sized fintech in Austin — had forwarded it with one word: "Finally."

After nearly ten years of security researchers banging on the same drum, AWS has introduced account-regional namespaces for S3 buckets. The change effectively kills bucketsquatting, one of the most persistent and quietly dangerous attack vectors in cloud computing. And if you're sitting there thinking "I've never heard of bucketsquatting," well, that's part of the problem.

What Bucketsquatting Actually Is (And Why It Kept Me Up at Night)

Here's the quick version: S3 bucket names are globally unique across all of AWS. When you delete a bucket, that name goes back into the pool. Anyone — literally anyone with an AWS account — can register it. If your application, CloudFormation template, or deployment script references a bucket by name, an attacker who snatches that name now controls where your data goes.

I first stumbled into this problem in 2021 when I was auditing a client's infrastructure. They had a staging environment that referenced projectname-us-east-1 — a bucket they'd deleted six months earlier. The bucket was gone. The reference wasn't. Some generous soul on the internet had already registered it. (Thankfully, they hadn't done anything malicious with it yet. We got lucky.)

Sandra, who leads our cloud security team, puts it bluntly: "Bucketsquatting is like leaving your house key under the mat, moving to a new house, and forgetting the key is still there. Except someone else moved in."

The New Account-Regional Namespace — How It Works

AWS's solution is elegant in its simplicity. New buckets can now follow this naming convention:

yourprefix-accountid-region-an

For example: myapp-123456789012-us-west-2-an

The -an suffix stands for "account namespace." When you create a bucket with this pattern, AWS validates that the account ID in the name matches your actual account. If someone else tries to register a bucket with your account ID in the name, they get an InvalidBucketNamespace error. Simple, bulletproof, and about seven years overdue.

The researcher who first documented this problem back in 2019 — Ian Mckay, known for his One Cloud Please blog — confirmed the fix works across dozens of test scenarios. He'd been communicating with AWS Security Outreach for almost a decade across "dozens of individual communications." That's a polite way of saying he's been yelling into the void since the first Obama administration ended.

The Real-World Damage Nobody Talks About

Tom, a DevOps engineer I worked with at a healthcare company in 2023, told me about an incident that never made the news. A contractor had deployed a CloudFormation stack that created buckets with a region-suffix pattern: appname-eu-west-1, appname-us-east-1, and so on. When the contractor left and the project was decommissioned, the buckets were deleted but the template lived on in a shared repository.

Eight months later, another team redeployed from that template. Except now, two of those bucket names belonged to someone else. Patient intake forms were briefly routed to a bucket controlled by an unknown third party. Tom described the incident review meeting as "the quietest room I've ever been in."

This isn't an isolated case. AWS's own internal teams fell victim to the same pattern — using predictable naming conventions like service-region that were trivially guessable. Ian Mckay documented multiple instances of AWS-published templates and documentation referencing deletable, squattable bucket names.

What You Need to Do Right Now

Here's the uncomfortable truth: this fix only applies to new buckets. Your existing buckets are still vulnerable if you ever delete them. So here's a practical checklist, courtesy of a 3 AM conversation with Rachel, our principal security architect:

1. Audit every S3 reference in your codebase. Search for hardcoded bucket names in CloudFormation templates, Terraform configs, CI/CD pipelines, application code, and documentation. Rachel built a grep pattern that caught 23 references we'd missed in our own infrastructure.

2. Create new buckets with the namespace pattern. For every critical bucket, create a new one using the prefix-accountid-region-an format. Migrate your data. Update your references. Yes, it's tedious. No, there's no shortcut.

3. Enforce the namespace via SCP. AWS now provides an s3:x-amz-bucket-namespace condition key. Add it to your Organization's Service Control Policies. This prevents anyone in your org from creating legacy-style buckets going forward. Dr. Patel at our compliance team called this "the first SCP condition key I've been genuinely excited about," which tells you everything about how compliance teams celebrate.

4. Never delete a bucket you might reference again. If you must delete it, scrub every reference first. Then wait. Then check again. Then maybe wait some more.

What About Azure and GCP?

This is where it gets interesting. Azure Blob Storage uses storage accounts that are namespaced to your subscription — they're not globally unique in the same dangerous way. GCP Cloud Storage has globally unique bucket names (similar to AWS), but they've had a project-based ownership verification since 2020 that mitigates the worst squatting scenarios.

AWS was, frankly, the last major cloud provider to address this at the platform level. Better late than never, but "late" here means approximately 4,380 days of vulnerability since the problem was first publicly documented. (Yes, I calculated that. It was a slow Tuesday.)

The Bigger Lesson

Bucketsquatting persisted for a decade not because it was technically complex, but because it fell into that frustrating gap between "obvious to security people" and "not urgent enough for the platform team." It's a pattern we see over and over: the vulnerability that's just boring enough to deprioritize.

Derek sent me one more message after the announcement: "So, what's the next obvious thing that'll take ten years to fix?" I told him I had a list, but sharing it would probably violate several NDAs and at least one unspoken social contract.

The fix is here. It works. Now go rename your buckets before someone else decides they want them.