That's absurd. Of course there are businesses that want hard ceilings. Perhaps not on their production website[1], but on clusters handed over to engineers and whatnot for projects, experimentation, etc.? I've seen these things lay around for months before they were noticed.
[1] Maybe you don't consider startups 'real' enough, but I can totally imagine early stage startups wanting limits on their prod website, too. You can't save CPU cycles for later consumption.
Are you sure? I'd imagine many startups would rather take a few hours of downtime over billed thousands erroneously. The latter could easily mean the end of the company but the former, when you are just striking out is not the end of the world by far.
I know startups that I could bankrupt with a few lines of code and a ~$60 server somewhere long before they'd be able to react to a billing alert if it wasn't for AWS being reasonably good about forgiving unexpected costs.
I'm not so sure no one running a "real business" would like a harder ceiling to avoid being at the mercy of how charitable AWS feels in those kinds of situations, or when a developer messes up a loop condition, or similar.
Perhaps not a 100% "stop everything costing money" option that'd involve deleting everything, but yes, some risks are existential enough that you want someone to figuratively pull the power plug out of your server on a seconds notice if you have the option.
If you can't afford downtime you probably can afford to wait for the alert and choose your own mitigation strategy. A system that can't tolerate downtime probably has an on-call rotation and these triggers ought to be reasonably fast.
If you can't react or can't afford to react, you probably can afford some downtime / data loss.
So the system doesn't need to have granular user defined controls. Just two modes. That was my point.
I think I triggered people with the phrase "real business" and I apologize for that.
Only a tiny fraction of businesses can't afford downtime. A lot of businesses claim they can't afford downtime, yet don't insure against it, and don't invest enough in high availability to be able to reasonably claim they've put in a decent effort to avoid it.
In most cases I've seen of businesses that claim they "can't afford downtime", they quickly balk if you present them with estimates of what it'd cost to even bring them to four or five nines of availability.
> A system that can't tolerate downtime probably has an on-call rotation and these triggers ought to be reasonably fast.
A lot of such systems can still run up large enough costs quickly enough that it's a major problem.
> If you can't react or can't afford to react, you probably can afford some downtime / data loss.
I'd say it is the opposite: Those who can afford to react are generally those with deep enough pockets to be able to weather an unexpected large bill best. Those who can't afford to react are often those in the worst position to handle both the unexpected bill and the downtime / data loss. But of the two, the potential magnitude of the loss caused by downtime is often far better bounded than the potential loss from a crazily high bill.
No one running a real business on AWS wants a hard ceiling instead of billing alerts and service by service throttling. Which Amazon has.
So, this is just the nuclear option for people's pet projects. It's not a bad thing to have but I wouldn't expect it to operate any differently than what would happen if you broke the TOS and they suspended your account.