[ahmedfromtunis]

Here's an idea: let users set a spending limit.

If they're about to go over, shoot them a quick heads-up and give them 24 hours to sort things out or level up their package.

After that, if they haven't made any changes, temporarily pause their site access

[skeeter2020]

AWS budgets are good for the first part, but they have no interest in a hard cap for obvious reasons.

[gazelle21]

Im out of the loop, what obvious reasons?

[dns_snek]

They profit when their customers can't hard limit their spend and end up racking up large bills by accident, or for reasons outside of their control.

By the way, your comment was flagged which seemed odd, so I looked at your profile and it seems like all of your comments are being (automatically?) flagged and don't appear on HN by default. You might want to talk to the HN staff about that.

[nemothekid]

1. This doesn't seem like a rational thing to do. A trillion dollar business built on people making mistakes and actually running up a bill? Which exec is getting a bonus when little Johnny gets hit with a $1000 charge on his CS101 project? Doesn't seem likely.

2. To me, it's more likely they don't have one because there are edge cases to consider that make "hard limits" difficult to implement. What is AWS supposed to do when you hit the limit? Is it a hard limit? Ok, so when I hit my budget, all my s3 buckets get deleted and all my EBS drives get dropped? Do all my code deployments just get deleted? Do you "bless" certain services so that they continue to charge the user even after the hard limit? How is all of this communicated?

You can set an alarm in AWS today and the user can decide what to shut off. If you really need to, you can create a script that can hard nuke your account once a limit is reached; but I don't see why AWS should nuke your account for you.

[dns_snek]

1. Even if you assume perfectly good intentions, they're not incentivized to fix the problem because they're not on the hook for the bill, but stand to profit from it. Their margins are eye-watering, so sending out a $100k bill for a service which cost them no more than $5 to provide doesn't have a downside (other than bad PR, which they seem to be blind to).

If providing this bandwidth cost them $50k rather than $5, I would bet you my entire life savings that they would QUICKLY find a way to add hard limits to their service, no matter what technical challenges they're quoting now.

2. This is probably a 95/5 problem. The vast majority of these sorts of cases that I've seen and read about are caused by increased traffic, which hits the customer either with extortionate egress fees or unintended compute scaling behavior (FaaS/VMs).

Storage is trickier, but you could stop accepting writes or reads after passing some hard limit.

This leaves some edge cases, sure, but it should handle the vast majority of unexpected bills without any destructive actions.

> You can set an alarm in AWS today and the user can decide what to shut off.

That shifts responsibility back on the customer, which is exactly the problem to begin with. I need assurances that I won't be billed more than $X in any given day, or month and this solution doesn't provide that. Maybe their API down, maybe it's serving stale data, or maybe my automation fails for some reason.

> How is all of this communicated?

Hard monthly limits:

Egress: [ $ 10 ] - When exceeded, all outbound traffic is limited to [ 0 Mbps ].

Compute: [ $ 10 ] - When exceeded, scale all compute instances to [ 0 ]

Data Storage: [ 1 TB ] - When exceeded, all writes are rejected

Reads Ops: [ $ 1 ] - When exceeded, all reads ops are rejected

It's really not that hard. Offer these limits on a per-project, or even per-resource level, that would naturally allow you to limit the blast radius. A personal website that has gone viral would likely want to have different limits than an email server under the same account, for example.

[nemothekid]

>If providing this bandwidth cost them $50k rather than $5,

No, I believe you are assuming that proving a "hard limit" feature is cheaper than just refunding people from time to time. If you consider the all the products AWS has to offer, all the different ways they are billed, then figuring out what do to for each product once that limit is reached, and potentially doing a destructive action, and then all the code and testing on top of that - it seems far easier to add a human in the loop to just refund people on a case by case basis. It's a ton of complexity for likely a rare issue, and if someone really needs it they can build one themselves and choose how to handle what needs to be done once the limit is reached.

Building all this out just so that some college kid isn't charged a bill they could obviously never pay likely isn't a good use of resources. It's not likely AWS has a reputation of being greedy either, if you explain the situation they refund you. If they are truly doing this to make money they have remarkably poor execution.

>It's really not that hard.

Storage pricing isn't done up front. You pay per gigabyte-month. If your "hard limit" kicks in, then what does Amazon do with the data you are no longer paying to store? Does Amazon drop your entire database once the credit limit is reached? There are plenty of Amazon services like this. Consider secret manager. You are charged 40 cents/month per secret. You have 100 secrets, so $40/mo, but you set your hard limit to $20. The middle of the month rolls around, what does Amazon do? Do they just drop all your encryption keys?

There are 100s of AWS services and many where you can't just apply a sensible rejection policy once you hit that hard limit without doing something the user cannot recover from. It's only not hard because you aren't actually thinking about the matrix of AWS products that exist and how they are billed.