[karmasimida]

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.

[BackBlast]

It's not hard to invert the transaction, ask the billing service if an action can be done instead of bill upon completion. Done. This isn't that hard. If your credits won't make it to the end of the month, send out the email warnings to top up - which should be predictable unless there's a large spike hitting the account. If you prefer invoice billing because you never want your services going down, it's trivial to accommodate with this system design.

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.

[derefr]

In theory, all IaaS services could be built like an Ethereum node:

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.

[gruez]

azure seems to manage that just fine with their free azure credit that they give to MSDN subscribers ($150/month spending limit, refilled every month, no chance of going over).

[halpert]

They bill by the request or minute for most of the services. Billing for storage is a little more complicated, but many services could easily be limited.

[heavyset_go]

Somehow Oracle of all companies is able to get this right with their free tiers for their cloud services.