By what logic is this NOT a terrible idea?
So that's why it's a great idea to implement data deletion as a two-phase sequence of synchronous key deletion, then asynchronous low-priority block scrubbing (or marking free for reclamation).
But not handling the case where your system is confused whether the keys are deleted (versus just temporarily unavailable) is less of a great idea.
...at the heat death of the universe
Yeah they come with a firewall but still. Imagine competing with everyone else on a single namespace.
At least for the s3 bucket is justified because those are meant to be accessible, but the databases?
not names. those are the limited conflicting resource, and they aren't arbitrarily nested:
"The server can contain only lowercase letters, numbers, and the hyphen (-) character" - "The domain name postgres.database.azure.com is appended to the server name you provide."
it also means I cannot just create parallel environments on their own subnet with the same scripts, I've to enter and manage configuration points for all the names, either as dns aliases or straight up in the application connection strings, and it also makes unnecessarily harder to just migrate the stuff around as needed to a failover node
i.e. rds advantage was zero downtime upgrades too, then and then sent a mail everyone last week with "we going to have 5 minute downtime to upgrade your db, whether it's multi zone with replicas or not"?
you can't trust them with that, the cloud is just somebody else computers', you need your own failover on top, and instead of changing one entry in the namespace I've to redeploy all clients, oh joy.