I Followed the Official AWS Amplify Guide and Was Charged $1,100

Spend limits are such an obvious and necessary feature that the only reason they don't have them is shady business practices.

Not really. Do you think that this is trivial at AWS scale? What do you do when people hit their hard spend limits, start shutting down their EC2 instances and deleting their data? I can see the argument that just because its "hard" doesn't mean they shouldn't do it, but it's disingenuous to say they're shady because they don't.

You shut down their instances and keep the data for a week and delete it if they don't pay promptly. It's not very profitable though.

set a policy for what happens when the spend limit is reached? not rocket science

> Do you think that this is trivial at AWS scale?

What a ridiculous point. AWS achieves non-trivial things at scale all the time, and brag about it too.

So many smart engineers with high salaries and they can't figure out a solution like "shut down instances so costs don't continue to grow, but keep the data so nothing critical is lost, at least for a limited time"?

Disingenuous is what you are writing - oh no, it's a hard problem, they can't be expected to even try to solve it.

At AWS engineering scale they can absolutely figure it out if they have the slightest interest in doing so. I've heard all the excuses — they all suck.

Businesses with lawyers and stuff can afford to negotiate with AWS etc. when things go wrong. Individuals who want to upskill on AWS to improve their job prospects have to roll the dice on AWS maybe bankrupting them. AWS actively encourages developers to put themselves in this position.

I don't know if AWS should be regulated into providing spending controls. But if they don't choose to provide spending controls of their own accord, I'll continue to call them out for being grossly irresponsible, because they are.

People kept up bringing this argument since the very beginning when people already asked for this feature. This used to be the most upvoted request on AWS forums with AWS officially acknowledging (back in 2007 IIRC), "We know it's important for you and are working on it". But they made a decision not to implement it.

The details don't matter, really. For those who decide to set up a hard cap and agree to its terms, there could be a grace period or not. In the end, all instances would be shut down and all data lost, just like in traditional services when you haven't paid your bill so you are no longer entitled to them, pure and simple.

They haven't implemented and never will because Amazon is a company that is obsessed with optimization. There is negative motivation to implement anything related to that.

> Disingenuous is what you are writing - oh no, it's a hard problem, they can't be expected to even try to solve it.

I find it funny people bring this pseudo-argument up whenever this issue is discussed. Customers: "We want A, it's crucial for us". People on the Internet: "Do you have any idea how difficult is to implement A? How would it work?" And the discussion diverges into technical details obscuring the main point: AWS is bent on on never implementing this feature even though in the past (that is more than a decade ago) they promised they would do that.

They've had two decades to figure it out. For EC2, they could shut down the instance but keep storage and public IPs. It shouldn't be too hard to estimate when the instance has to be stopped to end up with charges below the hard limit.

> What do you do when people hit their hard spend limits, start shutting down their EC2 instances and deleting their data?

Yes, why not? I don't see the problem here? If you didn't want that, you could set a higher spending limit.

If they want a little more user-friendly approach they could give you X hours grace.

> You've been above your spending limit for 4 hrs (200%), in 4 hrs your services will go into suspended state. Increase your spending limit to resume.

That, and AWS just doesn’t really care for people with a spending limit as their customers, which is entirely reasonable.

Just forgiving all the ridiculous bills is a much better (and cheaper) strategy.

That’s what Hetzner does.

I don't think it's particularly obvious or necessary. AWS makes its money on big enterprise customers who probably don't want or need this feature. Hobbyists learning AWS in their spare time are a rounding error on AWS revenue.

I would bet that the reason they don't implement it is not that they're being "shady" but because they don't care about the hobbyists and personal projects and implementing hard spending limits would be a huge, complicated feature to implement. And even if they did put in the huge effort to do it, individuals would still manage to not use it and the steady trickle of viral "I accidentally spent X thousands bucks on AWS" stories would continue as usual.

yes it's trivial for them, they are crazy rich and it's their core competence

Now multiply the logic required by multiple cost factors across hundreds of services.

When it's their money Azure manage to have a spending limit...

> The spending limit in Azure prevents spending over your credit amount. [1]

Once it's your money miraculously the spending limit is no longer available...

> The spending limit isn’t available for subscriptions with commitment plans or with pay-as-you-go pricing. [1]

[1]: https://learn.microsoft.com/en-us/azure/cost-management-bill...

> What a ridiculous point. AWS achieves non-trivial things at scale all the time, and brag about it too.

Many companies achieve non-trivial things at scale. Pretty much every good engineer I speak to will list out all the incredibly challenging thing they did. And follow it up with "however, this component in Billing is 100x more difficult than that!"

I've worked in Billing and I'd say a huge number of issues come from the business logic. When you add a feature after-the-fact, you'll find a lot of technical and business blockers that prevent you doing the most obvious path. I strongly suspect AWS realised they passed this point of no return some time ago and now the effort to implement it vastly outweighs any return they'd ever hope to see.

And, let's be honest, there will be no possible implementation of this that will satisfy even a significant minority of the people demanding this feature. Everyone things they're saying the same thing but the second you dig into the detail and the use-case, everyone will expect something slightly (but critically) different.

> "however, this component in Billing is 100x more difficult than that!"

Simply claiming this does not make it true. Anyway, the original claim was simply that it is not trivial. This is what is known as moving the goalposts, look it up.

> let's be honest, there will be no possible implementation of this

Prefixing some assertion with "let's be honest" does not prove it or even support it in any way. If you don't have any actual supporting arguments, there's nothing to discuss, to be honest.

Imagine how impossible it is to actually build those services, with all their logic, if just this added logic is impossible :)

> Simply claiming this does not make it true.

The people "claiming" this actually worked on it. I read a post from HN just yesterday talking about the complexities of billing. Look it up.

> If you don't have any actual supporting arguments

You can read other responses in this post. Look it up.

I didn't say it was impossible or even intractable. Its simply not as easy as everyone "why don't they justs."