Or simply returns 503? Why would you go directly to destroying things??

Suppose you’re going over the billing cap based on your storage consumption, how would AWS stop the continued consumption without deleting storage?

Why would they need to delete storage, they could just not accept past the cap.

Storage billing is partly time-based.

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.

I think most of the "horror stories" aren't related to cases like this. So we can at least agree most such stories could be easily avoided, before we looked at solutions to these more nuanced problems (one of which would be clearly communicating the mechanism of a limit and what would be the daily cost of maintaining the maxed storage - and for a free account the settings could be adjusted for these "costs" to be within free quota)

Not everything on AWS is a Web app

TCP session close? Don't reply back the UDP response? Stop scheduling time on the satellite transceiver for that account?

Interesting that you mention UDP, because I'm in the process of adding hard-limits to my service that handles UDP. It's not trivial, but it is possible and while I'm unsympathetic to folks casting shade on AWS for not having it, I decided a while back it was worth adding to my service. My market is experimenters and early stage projects though, which is different than AWS (most revenue from huge users) so I can see why they are more on the "buyer beware" side.

Everything on AWS can deny a request no matter what the API happens to be