Limiting billing is ambiguous. The computation spent is spent, unless AWS can predict how much you are going to cost by even initiating certain operation, which is not going to be straightforward for all the services they provided.
Sure, big warnings about data loss/services down in the event of zeroing out your credits.
Having such a safety net would really help the thousands of people who sign up for transient reasons. I don't recommend a noob set up an AWS account. I also don't let my kids play on the freeway.
1. fill an account with abstract "multi-resource usage credits" (or gas);
2. have each API call specify how many credits the caller is willing to spend from their account on the operation (a gas limit);
3. operations in progress are tracked using real-time resource accounting (= distributed tracing, but cheap-as-possible at the expense of granularity);
4. any operation that goes over-budget is cancelled (even if it completed successfully, the user doesn't get the benefit of that completion), with the user being charged exactly the limit they specified.
(Yes, that means that the IaaS eats the overhead costs of any additional processing they did before noticing and stopping the workload going beyond its limit. This incentivizes the IaaS to optimize their scheduling, at all levels of the stack, to minimize the amount of "overhang" work it allows.)
And yes, to be clear, this would "infect" every layer of every service. If the IaaS provided a DBaaS, the DB's query planning and execution layers would need to know about these limits and accounting mechanisms. Etc.
I'm not saying it's practical. But it's definitely possible, with no foreknowledge of cost.