What would be helpful, would be if when you set up your account there was a default limit – as in an actual limit, where all projects stop working once you go over it - of some sane amount like $5 or $50 or even $500.
I have a handful of toy projects on AWS and Google cloud. On both I have budgets set up at $1 and $10, with notifications at 10% 50% and 90%. It’s great, but it’s not a limit. I can still get screwed if somehow, my projects become targets, and I don’t see the emails immediately or aren’t able to act on them immediately.
It blows my mind there’s no way I can just say, “there’s no conceivable outcome where I would want to spend more than $10 or more than $100 or whatever so please just cut me off as soon as I get anywhere close to that.”
The only conclusion I can come to is that these services are simply not made for small experimental projects, yet I also don’t know any other way to learn the services except by setting up toy projects, and thus exposing yourself to ruinous liability.
But, I don’t think the idea of just stopping charging works. For example, I had some of their machine image thingies (AMI) on my account. They charged me less than a dollar a month, totally reasonable. The only reasonable interpretation of “emergency stop on all charges completely” would be to delete those images (as well as shutting down my $500 nodes). This would have been really annoying, I mean putting the images together took a couple hours.
And that’s just for me. With accounts that have multiple users—do you really delete all the disk images on a business’s account, because one of their employees used compute to hit their spend limit? No, I think cloud billing is just inherently complicated.
I disagree; a reasonable but customer-friendly interpretation would be to move these into a read-only "recycle bin" storage for e.g. a month, and only afterwards delete them if you don't provide additional budget.
https://docs.aws.amazon.com/accounts/latest/reference/manage...
The difference is that cloud providers charge you for the “at rest” configuration, doing nothing isn’t free.
Surely these billion and trillion dollar companies can figure out something so basic.
You don't stop CHARGING. You stop providing the service that is accumulating charges in excess of what limit I set. And you give some short period of time to settle the bill, modify the service, etc. You can keep charging me, but provide a way to stop the unlimited accrual of charges beyond limits I want to set.
> No, I think cloud billing is just inherently complicated.
You're making it more complicated than it needs to be.
> The only reasonable interpretation of “emergency stop on all charges completely” would be to delete those images.
It's by far certainly not the 'only reasonable interpretation'.
"Stop all charges" is a red herring. No one is asking for a stop on charges. They want an option to stop/limit/cap the stuff that causes the charges.
That _also_ runs into problems!
Take, for example, a nightly job that spins up a few giant instances to do some batch processing and shuts them down. Running an hour a night, over the course of the month that's going to accumulate ~$300 in charges. Great, we can set a $400/mo budget and have some wiggle room and all is well!
But how can AWS know that you're going to shut the instances down? Looking only at the rate charges are accumulating, the first night those instances start up you are on track to run up a $7,000 bill!
So do we set a $400/mo budget and then just kill the account so it stops accumulating charges when we hit $400, or do we set a $7,000/mo budget to account for the potential rate of accumulation and risk exceeding our budget by 2,000%?
It would be nice if this were in fact just overcomplicating things, but after much thought and many arguments on the internet I really can't see an easy "general" solution to this. The solution is heavily dependent on your specific workload and usage patterns, and the tooling is there to manage that if you want: Create billing alerts, and run code to adjust your usage in response to them.
That all said: I would fully support some sort of "developer sandbox" account that allowed a "kill the account" billing limit. I'd really prefer it had some sort of obvious limitation to avoid people accidentally using it for production workloads or dev workloads turning into production ones. Something like a hard limit that shuts the account down in 30 days, or limiting inbound connectivity to only via a VPN or something. That's purely self interest though--I don't want to see the article on the top of HN every few weeks about how "Amazon killed my startup" because someone set a billing limit and then all their customers' data was deleted.
Might work. I do think that part of the appeal of these types of services is that you might briefly want to have a very high $/sec. But the idea makes sense, at least.
As someone else pointed out, some(?) services prevent unlimited autoscaling, but even without unlimited, you may still hit a much larger limit.
Being able to say 'if my bill goes above $400, shut off all compute resources' or something like that. Account is still on, and you have X days (3? 1? 14?) to re-enable services, pay the bill, or proceed as you wish.
Yes, you might still want some period of high $/sec, but nearly every horror story in this vein ends with an issue with the final bill. Whether I burn $300 in 5 minutes or 26 days, I want some assurance that the services that are contributing most to that - likely/often EC2 or lambda in the AWS world - will be paused to stop the bleeding.
If you could pipe "billing notification" SNS message to something that could simply shut off public network access to certain resources, perhaps that would suffice. I imagine there's enough internal plumbing there to facilitate that, but even then, that's just AWS - how other cloud providers might handle that would be different. Having it be a core feature would be useful.
I was on a team that had our github CI pipeline routinely shutdown multiple times over a few weeks because some rogue processes were eating up a lot of minutes. We may have typically used $50/$100 per month - suddenly it was $100 in a day. Then... $200. Github just stopped the ability to run, because the credits used were over the limits. They probably could run their business where they would have just moved to charging us hundreds per day, perhaps with an email to an admin, and then set the invoice at $4500 for the month. But they shut down functionality a bit after the credits were exhausted.
Compute and API access to storage is usually the thing that bites people with cloud costs.
I want an option that says if I go over $20 on my lambda costs for lambda X, shut it off. If I go over $10 on s3 reads, shut it off.
Most (aws) services support limits which prevents unlimited autoscaling (and thus unlimited billing)
I'm sorry but this is complete bullshit. they can set a default limit of 1 trillion dollars and give us the option to drop it to $5. there's a good reason they won't do it, but it's not this bullshit claim that's always bandied about.
What happens to your files when you refuse to pay the bill?
Now, as to why they're applying the dark pattern - cynically, I wonder if that's the dark side of usage/volume based pricing. Once revenue gets big enough, any hit to usage (even if it's usage that would be terminated if the user could figure out how) ends up being a metric that is optimized against at a corporate level.
I suppose you could bake the limits into each service at deploy time, but that's still a lot of code to write to provide a good experience to a customer who is trying to not pay you money.
Not saying this is a good thing, but this feels about right to me.
And frankly any pay-as-you-go scheme should be regulated to have maximum spending limit setting. Not only in IT.
You're right in that there's a few services that expose this complexity directly, the ones where you're paying for actual storage, but this is just complex, not impossible.
For one thing, storage costs are almost always static for the period, they don't scale to infinite in the same way.
https://medium.com/%40akshay.kannan.email/amazon-is-refusing...
Yeah, I'm sure this is it. There is no way that feature is worth the investment when it only helps them sell to... broke individuals? (no offense. Most individuals are broke compared to AWS's target customer).
