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.
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.
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.
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.
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.
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.
6 replies →