Amazon refuses to set up bill capping, even though users have been asking for it for many years: https://forums.aws.amazon.com/thread.jspa?threadID=58127&sta...

In a past life as a cloud (VDN) provider, this was a real trade off.

When you have customers doing events, it’s more often that the scale up is from a real event than that someone fat fingered a config.

If they are broadcasting an unscheduled Obama speech from home page of a major paper, that’s not the time to go “Oh, anomalous, shut it down.” By the time that gets fixed and back on, Obama’s left the building - and your customer leaves too.

If you are in the business of offering a service with “elasticity” as a core capability, we found it better for SLOs and better for the bottom line to ‘fix’ this after the fact by discussion than to attempt to tell real spikes from glitches.

If you don’t want elasticity, you might not be looking for “cloud”.

If you really wanted, you could create a script that after a certain billed amount gets reached switches your site via route53 over to a static s3 page that says "down for maintenance" or something until you figure out why your forecasted billing amount is so high. forcastedSpend is an object you can call via api: http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/...

and a SDK like boto3:

http://boto3.readthedocs.io/en/latest/reference/services/bud...

That wouldn't have made much of a difference in the particular case of this article.

EDIT: I've reposted my question as a top-level comment to give it a bit more visibility as I'm interested in seeing answers as to what would be a fair price for such a service.

https://news.ycombinator.com/item?id=14984330

Amazon has always been happy to DDOS your wallet - one of their whitepapers a few years back on how to survive a DDOS attack was "out scale it".

I can't imagine this changing.

OTOH, for anything that's not a toy project, this is one of the viable approaches. Power tool is powerful (which also means you can hurt yourself using it), news at 11.

> Never use a pay-per-use service that does not include a reasonable "turn off after $X" feature and appropriate warnings.

None of the "Cloud providers" offer that. They "claim" that it could impact service - yeah, service of debt that you owe them.

Azure has this. When you hit your spending limit, it shuts down your services.

They didn't a year and a half ago. Created a 3k bill for my employer over RemoteApp. Yeah, charge per user, they said. Oh yeah, min 20 users, and we round up - of course in small print at the time.

Unless I have hard guarantees, I give "cloud providers" re-loadable cards. Can't take more money than what's on there.

The vendor could still assign the debt to a collection agency or sue; a declined charge does not get you off the hook unless they decide it's not worth pursuing.

That's very true. That's why I provide generic usernames and everything. Because how the current providers offer service is as through a debt system. You rack up the $$$, and they tell you after the fact.

I would greatly prefer to pay up front, and have services take my credit. That way, I could control my costs directly and concisely. No surprise billing. DOS'es get stopped by no more funds- they aren't the infinite money piggybank they are now with debt.

I also understand why some clients would want a debt based system where they can expand and contract their costs. I'm cool with that, as long as you know what you're signing up for. The person in this article didn't, and surprise billing is majorly at fault here.

My solution would stem this "You owes us $20,000 by end of month", to "Your credit is exhausted after 10 minutes. Something seems wrong with this account cwhen compared to history."

If you're out of credit, what happens to your data-at-rest? You know, the stuff you're storing in their block storage, where they charge just for storing it? Should they just purge your data?

It's been around a while, but I looked into it and it looks like it's based on the type of account you have[0]. I've only had the accounts that had spending limits as an option. I'd imagine a lot of people are on Pay-As-You-Go, so many people won't have the ability to set spending limits. Frustrating that they would lock these features behind different plans.

[1] https://azure.microsoft.com/en-us/support/legal/offer-detail...

They can terminate your AWS/Azure/DO account though.

And now we wait for the first reports of production services that were shutdown due to spending limits :)

I would rather production go down for a bit than have the whole company go bankrupt

Or you bankrupt them by not having them shut off. Its a CoS - Cost of Service attack

This always comes up but people seem to just ignore the complexity: What exactly is supposed to happen when the spend hits your budget?

Even a few bytes sitting on S3 continue to incur charges and it's hard to be real-time with spend tracking at the scale of these providers so the only option they have is to delete your entire account immediately. Is that what you want? Who would?

For most companies, business continuity matters. The proper solution is to use the budget and reporting features to check your work.