The solution is simple: budget caps.
Having said that, within AWS there are the concepts of "budget" and "budget action" whereby you can modify an IAM role to deny costly actions. When I was doing AWS consulting, I had a customer who was concerned about Bedrock costs, and it was trivial to set this up with Terraform. The biggest PITA is that it takes like 48-72 hours for all the prerequisites to be available (cost data, cost allocation tags, and an actual budget each can take 24 hours)
Implementing that functionality across AWS would cost orders of magnitude more than just simply refunding random $100k charges.
Sure, not providing that customer-friendly feature bestows them higher profits, but that’s exactly the criticism.
If it were highly profitable for them to implement some form of budget cap cutoffs, they would! It's obvious it's not a game they are interested in.
Imagine the horror stories on Hacker News that would generate.
Maybe rather than completely stopping the service, it'd be better to rate limit the service when approaching/reaching the cap.
EBS is billed by the second (with a one minute minimum, I think).
Once a customer hits their billing cap, either AWS has to give away that storage, have the bill continue to increase, or destroy user data.
One of those things is more important to different types of business. In some situations, any downtime at all is worth thousands per hour. In others, the service staying online is only worth hundreds of dollars a week.
So yes, the solution is as simple as giving the user hard spend caps that they can configure. I'd also set the default limits low for new accounts with a giant, obnoxious, flashing red popover that you cannot dismiss until you configure your limits.
However, this would generate less profit for Amazon et al. They have certainly run this calculation and decided they'd earn more money from careless businesses than they'd gain in goodwill. And we all know that goodwill has zero value to companies at FAANG scale. There's absolutely no chance that they haven't considered this. It's partially implemented and an incredibly obvious solution that everyone has been begging for since cloud computing became a thing. The only reason they haven't implemented this is purely greed and malice.
Sounds like you're saying "there aren't caps because it's hard".
> If you want hard caps, you can already do it. ... the capability is there.
What technique are you thinking of?
Set it up so that machines are deleted, but EBS volumes remain. S3 bucket is locked-out but data is safe.