Out of curiosity, can there not be something like a two party or N party veto? i.e. requiring a minimum of two or N parties to work together to veto?
The choice between just a single party having a veto power vs no party with veto powers seems a little black and white to me. Happy to be enlightened on the matter.
I just checked again. 16GB DDR5 (291 Euro) to 32GB (519 Euro). Seems right to me and does not match what you reported. Maybe they updated the website by the time I checked.
I checked the prices for 64GB DDR5. There's some variance based on brand/model but the average and trend seems more or less right. Did you happen to notice that it is about prices in the EU?
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.
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.
This is not me criticising you. I totally understand the urge to say it. We're all thinking the thing you're thinking of. It takes effort not to give into it ;)
The reason I personally would refrain from making such comments is that they have the potential to end up as highest ranked comment. That would be a shame. Topic of S3 bucketsquatting is rather important and very interesting.
S3 has much bigger fish in its sight than the measely vector db space. If you see the subtle improvements in features of S3 in recent years, it is clear as day, at least to me, that they're going after the whale that is Databricks. And they're doing it the best way possible - slowly and silently eating away at their moat.
AWS Athena hasn't received as much love for some reason. In the next two years I expect major updates and/or improvements. They should kill off Redshift.
The choice between just a single party having a veto power vs no party with veto powers seems a little black and white to me. Happy to be enlightened on the matter.