You'd be surprised how great it is to pass a parametized query and have it turned into a function quickly.
Doing stupid things on AWS is really easy and sadly billing can be up to 24 hours delayed.
You'd be surprised how great it is to pass a parametized query and have it turned into a function quickly.
Doing stupid things on AWS is really easy and sadly billing can be up to 24 hours delayed.
How about we call it auto-snailing. "I wanted to grow fast, but not THAT fast! Slow it down there buddy."
There are lots of posts online that document "talk to amazon and they'll take out the extra charges" but there are even more cases where the people just pay the bill and thus amazon makes money and profit.
Additionally, bill cutting is not that easy. Should they shut down current services? Stop sending in the middle of a newsletter? Delete your S3 Storage? Even then, a large company might accumulate hundreds or thousands of dollars within a second ; even if they decide to cut at all cost, minimal delays might break the limit.
I fully agree that it sucks for experimenting; it is very much the reason I don't have an AWS account. But I can see why they don't have it.
The problem is there's not a clear way to tell the difference between recursive calls and heavy traffic.
AWS components are fundamentally a network of nodes that are sending traffic to other nodes. But there's no unifying language that can model this, so you can't describe what this graph ought to look like. (e.g. you want to be able to say "lambda Foo should be called twice for each event to Bar".)
And that'd be hard to do since most nodes are general purpose computers, like Lambda and EC2, that can send traffic anywhere for arbitrarily complex reasons.
Since you can't describe what it ought to look like, trying to alarm on it becomes a problem of detecting anomalies. You can sort of do it, but AWS doesn't want to do it because they'd be making a promise they couldn't generally keep.