My belief, and you can correct me on this if you have evidence to the contrary, is that nobody actually pays those bills.
Someone paid those bills to somebody. AWS has costs incurred from it (support, opportunity, etc) and they paid them.
From that point of view, the cap seems more like a common-sense self defense feature that the cloud provider would want to implement. But we have cloud providers in this thread saying they don’t want to implement caps, so, I dunno.
There is a very obvious fix for surprise billing. Enforce a billing cap and terminate service if it's met. Even better if you send alerts when the cap is approaching. If I pay $39/month, a default cap should be $39 per-month. Otherwise, let me set a cap I am comfortable with. Surprise billing is never good for customers, only the business.
I promise, you are not the first person to have thought of this, and, believe it or not, there are reasons other than malice and avarice that cloud providers don't terminate service based on billing caps. Terminating service is a big deal. We agree completely about surprise billing.
When you build an app for resiliency you end up with classes of service where the app fails in stages.
But to extend that to the billing case, you’d have to have a partnership with your customers, not just a dashboard where they push buttons and an API where you add or delete machines.
Maybe the website goes read only except for admin traffic when the budget is exceeded, for instance. Not as a bespoke process each company has to reinvent, but as functionality provided by the vendor.
In other words, they are socializing the costs. Servers and electricity aren't free. Wouldn't it be better for the customer if they had no accident forgiveness and passed those cost savings along? Instead, you are paying for other peoples mistakes plus all the extra overhead caused from fraud that they incentivized.
The servers are already bought; the electricity cost is negligible for actual accidents.
As mentioned in the post: the hosting providers don't actually pay marginal costs for transient mistakes, so neither should honest customers.
The only thing in cloud that's worse than a surprise bill is a surprise outage.
This made me think. There is usually some "hard" cost limit X that you cannot / don't want to afford, so terminating the service is preferable. There is also usually some "soft" limit Y Y than face an outage. But a hard limit would have to be set to X to avoid that outage, and if it gets exceeded, you'll face a bill of X and an outage. So what a customer would actually need is to specify both X and Y, with the rule:…
Is this a soft limit or a trajectory prediction? I think there isn’t such a thing as a soft limit. Nobody wants to spend any money really right? But you need to spend some to avoid losing service. That’s just a cost you don’t like but need to pay.
I definitely get the idea of: I don’t want to spend X so if it looks like I will, terminate service at Y. But I think that’s a special case of the general situation, I want to know how much I’m on track to spend, right?
But I don’t know much about this at all. My whole experience was accidentally getting my own personal self a $500 AWS charge and then deciding they cloud services were dumb.
Perhaps that is true, but the stress and anxiety from seeing 100K bill is real and has an impact. https://www.forbes.com/sites/sergeiklebnikov/2020/06/17/20-y...
If you're stressed over lighting $100k on fire, then you're not the target market. /s
Then how do AWS, Azure and GCP charge 100 times the amount for bandwidth as other hosting providers and the IP transit quote sitting in my email inbox?
Why isn't one of those providers roflstomping the other 3 (add OCI to the mix) with better pricing?
With such a small group, chances are they all figured out that a race to the bottom won’t reach the desired long term outcome.
In your article or in the posts here you have not said why you think its a crazy idea.
I've said it over and over again: if you have a serious app, and someone somehow steals a credential from you and uses it to light up a bunch of crypto miners, you don't want us shutting down your main app in response. We perceive it mostly as a feature that will blow people up. We agree about the underlying problem! You don't want to spend $5000 in a month for services you never wanted. We don't want you spending th…
I think your position is essentially that you mostly want to serve people who have serious apps, for whom the cap idea doesn’t work. And you definitely know more about the general trajectory of your customers than all of us sitting here randomly speculating. But, is it really so uncommon for an application to transition from unserious, I want to cap, to serious?
I guess I’m slightly confused because I thought one of the nice things about cloud services is that they give you the ability to fit your infrastructure to your size while you are trying things. If I’m still trying things, I might not even know if I’m serious yet, right?
You'll pay exactly the amount they think you can afford to pay and not a penny less.
That would be what you would pay in the absence of competition. This is an incredibly competitive space.
If the cost calculation is complex and opaque, that successfully prevents anyone from evaluating what their costs would be on a competing service. And vendor lock-in makes it expensive and nontrivial to simply try it out.
There is a very obvious fix for surprise billing. Enforce a billing cap and terminate service if it's met. Even better if you send alerts when the cap is approaching. If I pay $39/month, a default cap should be $39 per-month. Otherwise, let me set a cap I am comfortable with. Surprise billing is never good for customers, only the business.
When you're paying $39/month for something that generates $0/month, that is a very sensible policy.
When you're paying $50,000/month for something that generates $200,000/month in value, or if an outage can generate $100,000/month in costs, or if the people that can fix an outage cost $100,000/year, then it's not.
I think this sounds easy, but it’s actually quite nontrivial in practice. You need special handling of such a limit for each kind of resource. E.g. when my limit is reached to they remove the database, along with all backups, and all objects on S3? Since storage is billed, it should also be stopped when the limit is reached, right? I think in practice among companies paying most of their revenue, there’d be zero inte…
I don't think any of these requirements are necessary. A basic "if I reach my bill limit, turn off things that are billing" toggle would suffice for 80%+ of users, especially with better billing controls/per-team billing accounts. I think you run into more problems/user frustrations with a tenuous conditional-shut-off approach. My tinfoil hat is that a lot of cloud billing is accidental, probably from "lab environmen…
What if my bug was saving, like, way more data to the cloud than I expected, and suddenly having a big bill for the hard drive space my data is using up just sitting there? It would be a pretty dumb bug, but hey, you never know, right? In that case they have to choose to either delete my data or keep charging me, so I guess there isn’t an easy zero-cost “stop” option.