Hacker News Reader

Comment by noasaservice | Hacker News Reader

Azure supports hard stops on services with billing maximums. It does mean that stuff gets turned off if you enable that. Then again, as an individual, that's a superb way to control costs.

And since Scamazon doesn't do that and INSTEAD "gives" you a 1 month unlimited credit, there's no telling just how stratospheric your bill can be.

> AWS is really good at refunding you if you accidentally rack up a couple grand in surprise bills.

If there were hard limits, there'd be no need to beg AWS support for leniency, which they can capriciously choose you don't deserve.

View on HN

Azure doesn’t support spending limits on all subscription types though.

https://azure.microsoft.com/support/legal/offer-details/

Completely true. However if what you're doing is highly price sensitive and willing to accept downtime over ScaryBill, then this the option you all need. And it's completely (and I bet intentionally) not available on AWS. AWS's message is "bend over and we'll tell you how far and long".

Larger companies see $4k as a nothing; pay and move on. Household budgets, not so much.

If there were hard limits, that would also mean that the billing system is on the critical path for all systems, and not just an after-the-fact ETL.

Not necessarily. A cloud provider could retroactively cap charges at the hard limits, but only cut access to resources asynchronously. That's effective what happens when you complain now with AWS.

If AWS wanted to, they could absolutely implement a hard cap. It's not like letting some services run for a few hours until billing catches up costs them a lot of money.

What is true--not necessarily in order is:

- I suspect AWS in aggregate probably makes a fair bit of money on overages that a user eats but would have had a hard circuit in place if they could have, and

- Even reasonably designed hard circuit breakers (e.g. we cut off access to your stateful data unless you pay your bill but we won't delete it for 30 days) are still giving developers a potentially well-hidden foot-gun for a production environment that management might not actually want.

Just like in real life, if you run out of money you have to stop doing things.

> Just like in real life, if you run out of money you have to stop doing things

In real life when you hit your card's limit, your transactions get declined. Straight away.

I had this last month in a supermarket after my (personal) checking account didn't have enough money to cover my purchase, I'd completely forgotten to transfer money from my business account.

My bank wasn't prepared to let my account go overdrawn, not even by the equivalent of $20, which is absolutely their right.

Amazon, OTOH, benefits in lots of ways by not implementing this mechanism.

A better analog to the store and Scamazon's implementation would be:

You put stuff in your cart.

You go through the register. You agree to "prevailing price".

No prices show up because they are "calculating".

You leave the store.

A day later, you're hit with a surprise bill that's 10-100x more than you though. A $100 transaction ends up being $1000-$10000.

There's no refunds.

The dispute procedure is to beg and hope they "let you ignore it".

> In real life when you hit your card's limit, your transactions get declined. Straight away.

Except for when it doesn't. I've got two primary current accounts, one with a "legacy" bank in the UK and one with a modern bank. The legacy bank is happy to let me go into an unplanned overdraft, and charge me for the privilege of doing so.

> a "legacy" bank

"Been there, done that". Not there any more!

For dev system, I can't see why no hard limits.

For the companies I've worked for, having HARD limits on devs would put the C-levels minds at ease.

At this moment, any dev with AWS keys has an unlimited month-per-month credit line that the company is on the hook for paying. And at best is the hope and prayer that the billing notifications aren't utter shit.

Reply on news.ycombinator.com