There are other mitigations though: You can pass expected owner accountId on S3 operations and you can create SCPs that restrict the ability of roles to write to buckets outside the account. Unless you have an account that does many cross-account S3 writes, the latter is a simple tool to prevent exfiltration. Well, simple assuming that you're already set up with an Organization and can manage SCPs.

[0] https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket...

If you block name reuse globally, you introduce a new attack surface: permanent denial by squatting on retired names. Companies mess up names all the time from typos, failed rollouts, or legal issues. A one-shot policy locks everyone into their worst error or creates a regulatory mess over who can undo registrations.

Namespaces are annoying but at least let you reorganize or fix mistakes. If you want to prevent squatting, rate limiting creation and deletion or using a quarantine window is more practical. No recovery path just rewards trolls and messes with anyone whose processes aren't perfect.

That would be a huge breaking change. Any workload that relies on re-using a bucket name would be broken, and at the scale of S3 that would have a non-trivial customer impact.

Not to mention the ergonomics would suck - suddenly your terraform destroy/apply loop breaks if there’s a bucket involved

Potential reasons I can think of for why they don't disallow name reuse:

a) AWS will need to maintain a database of all historical bucket names to know what to disallow. This is hard per region and even harder globally. Its easier to know what is currently in use rather know what has been used historically.

b) Even if they maintained a database of all historically used bucket names, then the latency to query if something exists in it may be large enough to be annoying during bucket creation process. Knowing AWS, they'll charge you for every 1000 requests for "checking if bucket name exists" :p

c) AWS builds many of its own services on S3 (as indicated in the article) and I can imagine there may be many of their internal services that just rely on existing behaviour i.e. allowing for re-creating the same bucket name.

I'd allow re-use, but only by the original account. Not being able to re-create a bucket after deleting it would be annoying.

I think that's an important defense that AWS should implement for existing buckets, to complement account scoped bucket.

I think a better policy would be to disallow bucket names that follow the account regional namespace convention, but don’t match the account id indicated in the name.