So I've stored some data in a bucket, the storage time goes over my budget, what do you do now? Just delete the data? I think most people would think that's a terrible outcome.

Let's say the answer is yes, you just delete all the data as I can no longer afford it... delete operations are billable, so do you charge the user for those deletes or not?

Let's say the answer is yes, and you bill the deletes. What happens if too many deletes are required and suddenly you're at 2x the bill cap? Now you can't document the bill cap as being able to go over by up to 1.5x. This may be unlikely, but customers use cloud services in weird and wonderful ways.

This is just one resource type, there are many different resource types on a typical cloud provider, each with multiple axes of billing, each of which has hard decisions to not just be made, but documented and communicated to customers in such a way that they understand the impact. Oh and also it's the "I just put my credit card in and go" crowd who you have to explain it to, who aren't engaging in sales conversations, not those on business contracts who might actually listen or read the documentation.

It's not at all obvious to me that this is preferable to just having someone look at these incidents on a case by case basis and seeing who should be refunded.

This is an insane take, there are many options here. The idea that the reason to structure billing this way is anything OTHER than that it's the most profitable way to do things is ludicrous. It doesn't matter if you can construct some other plausible reason, as long as it's the most profitable way to operate why would I believe the cause to be something other than profit maximization.

What alternative do you suggest? I'm not saying providers should delete data when hitting a cap, but rather that this is one example of why you can't cap spend.

It is possible to combine all the billing axes for things like this so that, but when you do you get Dropbox, or Google Drive. The explicit value proposition of cloud hosting is paying for what you use, and generally granular services are lower margin and more commoditised than higher level services.

You could just throw an error, freeze services and do whatever "let someone handle this on a case by case basis". It's absurd to suggest that the customer doesn't want to have the option to prevent their spend from growing by multiple orders of magnitude without a human in the loop. Sure maybe deletes are a billable action (also absurd and fake), but having the options to say "hey I can't spend more than X, cut my service if my spend + cleanup would cost more than X" is absolutely doable and something many people would want.

If you think that deleting all data (blob storage, block storage, VM states, caches, etc) is preferable to a surprise bill, then I don't think there's anything we can debate here.

I agree that there isn't anything we can debate here, but it's because you're making straw men. There's a middle ground here between getting charged 4 orders of magnitude more than you expected and having all of your data deleted that you're obtusely refusing to consider.

If writing data to a bucket would push the monthly cost for data storage over the budget, the write should fail, not succeed and then delete something else to get the data back under the limit. Why would you even consider doing it that way unless you're specifically going out of your way to write the worst possible form of billing cap?

That's clearly not user friendly. Users cannot predict the amount of overshoot. So we are back to square one. The user could wake up to a $1,000 bill or $10,000 bill and all data deleted, and the cloud provider can just say "oh we run our billing limit enforcer job on an hourly cron schedule but your account requested many machines very quickly so you still incurred $10,000 worth of charges." A precise billing limit is impossible, and a fuzzy billing limit with a precise error bound is the same thing and also impossible. Now we are back to a fuzzy billing limit with an unknown error bound.