[XorNot]

Worked for a company which ran into an S3 bucket naming collision when working with a client - turns out that both sides decided hyphenated-company-name was a good S3 bucket name (my company lost that race obviously).

One of those little informative pieces where everytime I do AWS now all the bucket names are usually named <project>-<deterministic hash from a seed value>.

If it's really meant to be private then you encrypt the project-name too and provide a script to list buckets with "friendly" names.

There's always a weird tradeoff with hosted services where technically the perfect thing (totally random identifiers) is too likely to mostly be an operational burden compared to the imperfect thing (descriptive names).

[cj]

What would encrypting the project name accomplish? Typically if you’re trying to secure a S3 bucket you’ll do that via bucket settings. Many years ago you had to jump through hoops to get things private, but these days there’s a big easy button to make a bucket inaccessible publicly.

[XorNot]

The point is that in some cases the name of the project might itself be considered sensitive in some way, so preventing people testing bucket names by trying to create them helps prevent it, but doesn't completely lock you out of being able to associate the bucket back to its internal name, and allows the names to be deterministic internally - i.e. someone spinning up a test environment is still getting everything marked appropriately, deterministically, and uniquely.

[brickteacup]

> The point is that in some cases the name of the project might itself be considered sensitive in some way

probably better to solve that problem by just giving projects easy-to-remember codenames. that's what intelligence agencies and militaries have been doing for years after all