Speaking of unique names within AWS, I learned the other day that even after you delete an AWS account, you can’t reuse the root user email addresses (it’s documented, but I wasn’t aware).
Someone at my org used their main company email address for a root user om an account we just closed and a 2nd company email for our current account. We are past the time period where AWS allows for reverting the account deletion.
This now means that he isn’t allowed to use SSO via our external IdP because the email address he would use is forever attached to the deleted AWS account root user!
AWS support was rather terrible in providing help.
show comments
vhab
> For Azure Blob Storage, storage accounts are scoped with an account name and container name, so this is far less of a concern.
The author probably misunderstood what "account name" is in Azure Storage's context, as it's pretty much the equivalent of S3's bucket name, and is definitely still a large concern.
A single pool of unique names for storage accounts across all customers has been a very large source of frustration, especially with the really short name limit of only 24 characters.
I hope Microsoft follows suit and introduces a unique namespace per customer as well.
show comments
josephg
Sometimes I wonder if package names, bucket names, github account names and so on should use a naming scheme like discord. Eg, @sometag-xxxx where xxxx is a random 4 digit code. Its sort of a middleground between UUID account names and completely human generated names.
This approach goes a long way toward democratizing the name space, since nobody can "own" the tag prefix. (10000 people can all share it). This can also be used to prevent squatting and reuse attacks - just burn the full account name if the corresponding user account is ever shut down. And it prevents early users from being able to snap up all the good names.
show comments
iknownothow
Thank you author Ian Mckay! This is one of those good hygiene conventions that save time by not having to think/worry each time buckets are named. As pointed out in the article, AWS seems to have made this part of their official naming conventions [1].
I'm excited for IaC code libraries like Terraform to incorporate this as their default behavior soon! The default behavior of Terraform and co is already to add a random hash suffix to the end of the bucket name to prevent such errors. This becoming standard practice in itself has saved me days in not having to convince others to use such strategies prior to automation.
About time. Cloud storage misconfigurations have been low hanging fruit for attackers for years. Surprised it took this long to close.
wrs
Once again AWS waits an inexplicably long time to fix an obvious deficiency that the other providers solved long ago, and then does it in an inexplicably hacky way.
See also their recent innovation of letting you be logged into the console with up to five (???) of the many accounts their bizarre IAM system requires, implemented with a clunky system of redirections and magic URL prefixes. As opposed to GCP just having a sensible system in the first place of projects with permissions, and letting you switch between any of them at will using the same user account.
ian_d
The _really_ fun bucket squatting attacks are when the cloud providers themselves use deterministic names for "scratch space" buckets. There was a good DC talk about it at DC32 for AWS, although actual squatting was tough because there was a hash they researchers couldn't reverse (but was consistent for a given account?): https://www.youtube.com/watch?v=m9QVfYVJ7R8
Once they are not renewed, they eventually become available again. Then anyone can re-register them, set up an MX record, and start receiving any emails still being sent to recipients in that domain. This could include password reset authentications for other services, etc.
saurik
AWS buckets still offer special features if and only if the name of the bucket matches your hostname.
A name shouldn't be the same as the thing it names.
When a name becomes free and somebody else uses it, it points to another thing. What that means for consumers of the name depends on the context, most likely it means not to use it. If you yourself reassign the name you can decide that the new thing will be considered to be identical to the old thing.
PunchyHamster
decision to make bucket (and not bucket + account id surrogate) a sole key for access was one of most annoying mistakes in S3 design
alemwjsl
I take it advertising your account id isn't a security risk?
show comments
arjie
Good solution. Thanks for popularizing it.
* Backwards compatible
* Keeps readability
* Solves problem
CafeRacer
While I understand where it's coming from I always had something like <bucket_tag>-<9_random_\d\w>
calmworm
That took a decade to resolve? Surprising, but hindsight is 20/20 I guess.
show comments
Bridged7756
I think I'm not getting it. What's the problem if someone else can claim that bucket name? If it's deleted wouldn't the data be deleted too? Or is it there something I'm missing.
show comments
thih9
> If you wish to protect your existing buckets, you’ll need to create new buckets with the namespace pattern and migrate your data to those buckets.
My pet conspiracy theory: this article was written by bucket squatters who want to claim old bucket names after AI agents read this and blindly follow.
peanut-walrus
Why the hell is this a name suffix instead of just using subdomains?
myapp-123456789012-us-west-2-an
vs myapp.123456789012.us-west-2.s3.amazonaws.com
The manipulations I will need to do to fit into the 63 char limit will be atrocious.
show comments
INTPenis
I started treating long random bucketnames as secrets years ago. Ever since I noticed hackers were discovering buckets online with secrets and healthcare info.
This is where IaC shines.
show comments
pooplord69
Does it still take like an hour to rename one?
ClaudeFixer
Good riddance. The number of production deploys I've seen pointing at bucket names that could've been claimed by anyone was wild. Glad this is finally getting closed off at the platform level instead of relying on everyone to not make the mistake.
show comments
amne
I hope nobody wanted "ecommerce-admin". sorry
Aardwolf
Why all that stuff with namespaces when they could just not allow name reuse?
show comments
lsaferite
I mean, why isn't this just the mandatory default going forward? Globally shared, unique bucket names always struck me as a horrible idea.
GuinansEyebrows
this seems nice but it's a little annoying if you've been using terraform's `bucket_prefix` to create buckets. i wonder if/when they'll update that or if they'll add a new bucket_name argument that uses the new namespacing.
Speaking of unique names within AWS, I learned the other day that even after you delete an AWS account, you can’t reuse the root user email addresses (it’s documented, but I wasn’t aware).
Someone at my org used their main company email address for a root user om an account we just closed and a 2nd company email for our current account. We are past the time period where AWS allows for reverting the account deletion.
This now means that he isn’t allowed to use SSO via our external IdP because the email address he would use is forever attached to the deleted AWS account root user!
AWS support was rather terrible in providing help.
> For Azure Blob Storage, storage accounts are scoped with an account name and container name, so this is far less of a concern.
The author probably misunderstood what "account name" is in Azure Storage's context, as it's pretty much the equivalent of S3's bucket name, and is definitely still a large concern.
A single pool of unique names for storage accounts across all customers has been a very large source of frustration, especially with the really short name limit of only 24 characters.
I hope Microsoft follows suit and introduces a unique namespace per customer as well.
Sometimes I wonder if package names, bucket names, github account names and so on should use a naming scheme like discord. Eg, @sometag-xxxx where xxxx is a random 4 digit code. Its sort of a middleground between UUID account names and completely human generated names.
This approach goes a long way toward democratizing the name space, since nobody can "own" the tag prefix. (10000 people can all share it). This can also be used to prevent squatting and reuse attacks - just burn the full account name if the corresponding user account is ever shut down. And it prevents early users from being able to snap up all the good names.
Thank you author Ian Mckay! This is one of those good hygiene conventions that save time by not having to think/worry each time buckets are named. As pointed out in the article, AWS seems to have made this part of their official naming conventions [1].
I'm excited for IaC code libraries like Terraform to incorporate this as their default behavior soon! The default behavior of Terraform and co is already to add a random hash suffix to the end of the bucket name to prevent such errors. This becoming standard practice in itself has saved me days in not having to convince others to use such strategies prior to automation.
[1] https://aws.amazon.com/blogs/aws/introducing-account-regiona...
About time. Cloud storage misconfigurations have been low hanging fruit for attackers for years. Surprised it took this long to close.
Once again AWS waits an inexplicably long time to fix an obvious deficiency that the other providers solved long ago, and then does it in an inexplicably hacky way.
See also their recent innovation of letting you be logged into the console with up to five (???) of the many accounts their bizarre IAM system requires, implemented with a clunky system of redirections and magic URL prefixes. As opposed to GCP just having a sensible system in the first place of projects with permissions, and letting you switch between any of them at will using the same user account.
The _really_ fun bucket squatting attacks are when the cloud providers themselves use deterministic names for "scratch space" buckets. There was a good DC talk about it at DC32 for AWS, although actual squatting was tough because there was a hash they researchers couldn't reverse (but was consistent for a given account?): https://www.youtube.com/watch?v=m9QVfYVJ7R8
GCP, however, has does this to itself multiple times because they rely so heavily on project-id, most recently just this February: https://www.sentinelone.com/vulnerability-database/cve-2026-...
DNS names have the same problem.
Once they are not renewed, they eventually become available again. Then anyone can re-register them, set up an MX record, and start receiving any emails still being sent to recipients in that domain. This could include password reset authentications for other services, etc.
AWS buckets still offer special features if and only if the name of the bucket matches your hostname.
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Virtua...
A name shouldn't be the same as the thing it names.
When a name becomes free and somebody else uses it, it points to another thing. What that means for consumers of the name depends on the context, most likely it means not to use it. If you yourself reassign the name you can decide that the new thing will be considered to be identical to the old thing.
decision to make bucket (and not bucket + account id surrogate) a sole key for access was one of most annoying mistakes in S3 design
I take it advertising your account id isn't a security risk?
Good solution. Thanks for popularizing it.
* Backwards compatible
* Keeps readability
* Solves problem
While I understand where it's coming from I always had something like <bucket_tag>-<9_random_\d\w>
That took a decade to resolve? Surprising, but hindsight is 20/20 I guess.
I think I'm not getting it. What's the problem if someone else can claim that bucket name? If it's deleted wouldn't the data be deleted too? Or is it there something I'm missing.
> If you wish to protect your existing buckets, you’ll need to create new buckets with the namespace pattern and migrate your data to those buckets.
My pet conspiracy theory: this article was written by bucket squatters who want to claim old bucket names after AI agents read this and blindly follow.
Why the hell is this a name suffix instead of just using subdomains?
myapp-123456789012-us-west-2-an
vs myapp.123456789012.us-west-2.s3.amazonaws.com
The manipulations I will need to do to fit into the 63 char limit will be atrocious.
I started treating long random bucketnames as secrets years ago. Ever since I noticed hackers were discovering buckets online with secrets and healthcare info.
This is where IaC shines.
Does it still take like an hour to rename one?
Good riddance. The number of production deploys I've seen pointing at bucket names that could've been claimed by anyone was wild. Glad this is finally getting closed off at the platform level instead of relying on everyone to not make the mistake.
I hope nobody wanted "ecommerce-admin". sorry
Why all that stuff with namespaces when they could just not allow name reuse?
I mean, why isn't this just the mandatory default going forward? Globally shared, unique bucket names always struck me as a horrible idea.
this seems nice but it's a little annoying if you've been using terraform's `bucket_prefix` to create buckets. i wonder if/when they'll update that or if they'll add a new bucket_name argument that uses the new namespacing.
Huh? Hash your bucket names