O_o

> ... Make it read only.

The primary use-case of s3 is reading objects. This would not be a deterrent for quite a few use-cases

> ... Pretend to delete it, but make recovery possible for x days.

Still consumes the space that they're charging for in the first place

> People who want a cap are going to more concerned with the overspend than any data or service integrity.

This is patently not true, and is why I think you don't really grok why implementing a cap is difficult. It's specifically why I said "everyone would demand different behaviour at the cap". Some would want only this or that service to stop, for example.

A small business sets up a payment cap and hits that cap because they went viral? BAM, all their block storage, destroyed. All their backups, their analytics, their RDS databases, just gone. Right at the time they needed it most.That's a much harder lesson to deal with than "oops, our bill's a bit high because we made a mistake, can you please forgive it?". Or even "ouch, okay we'll pay it". The protection you want for hobbyists would destroy small businesses that may not understand what is actually meant when that hard cap is hit. It's not that caps aren't doable at all, it's just that they're a wicked problem, and the more you look at it, the more issues you can see.

As for soft caps, what is the functional difference between a soft cap and the billing warnings they already have?

Also, their claim on s3 is "we don't lose objects". Destroying objects because of billing would utterly undermine that claim.

> If your payment methods gets declined I'm prepared to bet Amazon don't just let all your services continue running indefinitely because shutting them down automatically is too hard of a problem for them to solve.

AWS does not destroy your services because of late payment. Source: we've just been in late payment.