I use VPSs for personal use for exactly this reason - the bill's the same (small amount) every month, and if load spikes I'm happier not being able to handle it than handling it for a surprise Xx bill.

A few years ago I got a ~$3500 Amazon bill when someone broke into my account (through keys I'd inadvertently added to GitHub)[1].

I had no expectation of that money being waived, but Amazon did anyway.

Since then I've had billing alerts turned on at about the $150 mark (which is about double what my personal monthly Amazon bill is).

[1]: https://news.ycombinator.com/item?id=6911908

Shameless plug: I know this plug should not be here but I think I can help some people with cost problem via (the easiest automation platform for AWS)[1].

I have a startup plan where you can run 60 executions in a month free of cost. Just reach out to me via https://totalcloud.io/solutions.html and refer YComb.

[1]: https://totalcloud.io

Same here, with AWS specifically. I'm used to AWS so generally stay in that ecosystem. Designed a web app and backed part of it by lambda and api gateway. Via a surge in traffic, my monthly bill went from about $6/mo to $150 for a month. Didn't catch it until I got the bill for the month, the timing of which meant my next month's bill was about $80.

Only Amazon is adamant at refusing this, Microsoft already made it possible some years ago, and I believe Google too.

Azure doesn’t have it for pay as you go.

https://feedback.azure.com/forums/906772-cost-management/sug...

A 6+ year wait for such a reasonable feature sucks.

And they have it for almost all other plans, so the technology is there.

It sounds like an intentional product decision and not a technical obstacle.

You can? I have daily limits for my Google App Engine apps.

Firebase also has a fixed price plan that can shut off your app if it blows through quotas. It’s called “Flame”

Don't forget they are only warnings, they will not shut down your app and their update rate is not as frequent as you might expect.

App Engine PM: the GAE Daily Spend limits are hard caps that will shut down services when hit. They are different from the broader GCP Billing Alerts which are simply notifications.

The issue is that they only apply to certain GAE services (compute, legacy APIs, etc.) and not across the platform.

Thank you for correction!

If the concern is DB operations adding up you can lower your quota as well which will be strongly enforced and shut down your app.

You can limit the max concurrency of lambda functions which can help a bit here.

Imo the reason is this is for business/enterprise use cases configuring this wrong could be catastrophic, for side project/personal use cases its pretty well known you get 1 chance for a refund from the public clouds, after some manual checking to make sure you aren't trying to abuse the service.

Microsoft Azure has such a feature (although not for Enterprise users, which is evil), I´m surprised that AWS doesn´t.

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

You can set budget alerts, which aren’t as good, but they can let you know if the bill’s going off the tracks. I set up alerts at 50% and 75% of what I’m willing to pay and that’s gotten rid of my ‘unexpected bill’ stress.

I think there'd be two big issues - (1) what is reasonable behaviour when you reach your budget, and (2) the consistency of billing.

On (1), if you get to say the 14th of the month and run out of budget, what would be the expected behaviour? - shut down all your services? delete all your data so that's not incurring a charge too? It'd probably have to be configurable on a service by service basis, and that's an awful lot of complexity to introduce for a tiny minority of their revenue base.

On (2), their billing systems are almost certainly eventually consistent in logging and charging usage, so they'd either have to shut you down early in anticipation of delayed charges, or let any delayed charges bring you over budget. Either is liable to make customers fairly unhappy one way or the other.

The TL;DR version - it'd be nigh on impossible to have good UX with such a feature, would be complicated to implement, and it's not likely to move the needle on any metric they really care about considerably.

> it's not likely to move the needle on any metric they really care about considerably.

what about devs too scared to put their CC no in the till coz they've heard horror stories about being overcharged for mistakes? Just recently had to sort out a feature that a junior dev created using openstreetmaps coz they didn't want to be on the hook by putting their card into google maps... It was for an internal portal, usage wasn't even high enough to hit the monthly free tier!

Hour 1 experience also matters.

Why would a junior dev be using _their_ card details? Surely your company has a corporate billing account with Google for this purpose?

Perhaps I've misunderstood the situation, but if I were working as a dev at a company and was expected to provide my own card details to pay for APIs, I would walk out the door.

They were just told to make the portal as a learning teambuilding exercise, choice of tools was entirely up to them - i even told the person company would pony up for anything they ended up spending. HR was being a pain about getting card details(it's not easy getting that stuff in india)

The dude bounced off google maps as soon as he saw the form to enter payment info and went straight to open street maps.

> The dude bounced off google maps as soon as he saw the form to enter payment info and went straight to open street maps.

As he should. Unless you have in written form that the company will cover the exact expense, then no one should use a personal CC for work use.

Not everyone is a rockstar engineer in a top 5 company my guy, people have to start somewhere and paperwork is a huge show stopper in india in general.

from your comment history i see you're european.Europeans have way more protections and assurances in cases like this, india is a very different business environment...

> The dude bounced off google maps as soon as he saw the form to enter payment info and went straight to open street maps.

Sounds like a happy ending.

Was the choice of OSM a bad one?

Seeing as how i had to learn all the GIS jargon OSM uses by default, it was bad for me. It's not a bad choice but since we as a company can afford the easy of Google maps it's a waste of time

How did you manage to increase your bill 15x in Lambda?

It seems to have been a combination of a traffic surge and a third-party API being temporarily slow. The slow API meant that I ended up paying for more idle CPU time during the request round-trip.

I guess you had not setup any budget alarms.

The alarms are why it wasn't higher than 15x.

At what percentage you had the alarm then?

Amazon provides Billing Alarms for monitoring charges, which is very useful for anticipating unplanned cost surges:

- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitori...

Alarms are like a garage leaving you a voicemail message before doing $25k of repairs on your car. It’s ridiculous that I can’t set a hard cap on my spending.

I guess you could have the SNS topic invoke a lambda that shuts down the specific service if you wanted that but I agree a budgets feature would be nice, especially when provisioning test accounts for developers.

Fine and dandy, but you can't use Lambda in fedramp.

You can't use most aws things in fedramp scope.

On the flip side I would never want my real business to shut off. Hobby project yes! Real business no,

AFAIK it's already considered a best practice to set up separate accounts for development and production (https://blog.codeship.com/separate-aws-production-and-develo...). Having a hard cap on an account dedicated to development would help a lot IMO.

Assuming your revenue and your AWS bill are strongly correlated, I agree. However, when a free service or a bug can increase costs by orders of magnitude without a corresponding increase in revenue your choices are to eat it (not sustainable, for most of us), throttle, or stop. Throttling is hard, so stopping is often the best choice.

Disagree there, for a paid business.

If my business had 100k in revenue per month. Normal cloud spend is 2k per month.. some glitch made spend go to 2k a day. That sucks, and I hope I have good alerts to catch it within a day or two.. but telling my customers "screw you, bill messed up" for however long it took me to sort out the bug? I would not do that.

Sounds like the oomkiller. Sounds good in theory until it starts shooting processes in the head that you didn’t intend.

What would you like Amazon to do for stateful services? Should they stop and delete EBS volumes? What about databases? Simply shut them down? What happens when you lose data or it doesn’t come back up?

EBS volumes have a size, so there's an upper bound to the cost. Most of the storage is predictable, so if I try to allocate storage where the monthly cost of the raw storage is (ex) 10x my budget, I wouldn't have a problem with the request being denied.

For non-storage resources like EC2, network bandwidth, etc. I'd be fine with having a hard limit where everything just breaks, especially for stuff that's not production.

There could also be better, self managed quotas on resources. SES is a good example. AFAIK the quota is all or none across the entire account. IMO, it's not a good idea to give a user that needs to send (made up numbers) 1k emails per day credentials that can send 250k emails a day.

I have 3 AWS accounts. I don't keep anything in my main account. It's for billing only. I have a sub account for production that I try to keep pristine. I have a sub account for development and testing. It's the development account that scares me. I spend less than $50 per month. I'd rather have my whole development account de-allocated than get a bill for $1k.

As with all things just having the option would be nice, but it does not mean it is useful or a good idea for everyone to use it.

For personal stuff I would much rather a kill switch than a nasty surprise. For _some_ businesses, that is probably the wrong decision though.