Hacker News Reader

Comment by Dunedan | Hacker News Reader

Depends on various factors and of course the amount of money in question. I've had AWS approve a refund for a rather large sum a few years ago, but that took quite a bit of back and forth with them.

Crucial for the approval was that we had cost alerts already enabled before it happened and were able to show that this didn't help at all, because they triggered way too late. We also had to explain in detail what measures we implemented to ensure that such a situation doesn't happen again.

View on HN

Nothing says market power like being able to demand that your paying customers provide proof that they have solutions for the shortcomings of your platform.

Wait, what measures you implemented? How about AWS implements a hard cap, like everyone has been asking for forever?

What does a hard cap look like for EBS volumes? Or S3? RDS?

Do you just delete when the limit is hit?

It's a system people opt into, you can do something like ingress/egress blocked, & user has to pay a service charge (like overdraft) before access opened up again. If account is locked in overdraft state for over X amount of days then yes, delete data

I can see the "AWS is holding me ransom" posts on the front page of HN already.

A cap is much less important for fixed costs. Block transfers, block the ability to add any new data, but keep all existing data.

2 caps: 1 for things that are charged for existing (e.g. S3 storage, RDS, EBS, EC2 instances) and 1 for things that are charged when you use them (e.g. bandwidth, lambda, S3 requests). Fail to create new things (e.g. S3 uploads) when the first cap is met.

Does that mean fail to create rds backups? And that AWS needs to keep your EC2 instance and RDS instance running while you decide if you really want to pay the bill?

How about something like what runpod does? Shutdown ephemeral resources to ensure there's enough money left to keep data around for some time.

RunPod has its issues, but the way it handles payment is basically my ideal. Nothing brings peace of mind like knowing you won't be billed for more than you've already paid into your wallet. As long as you aren't obliged to fulfil some SLA, I've found that this on-demand scaling compute is really all I need in conjunction with a traditional VPS.

It's great for ML research too, as you can just SSH into a pod with VScode and drag in your notebooks and whatnot as if it were your own computer, but with a 5090 available to speed up training.

Yes, delete things in reverse order of their creation time until the cap is satisfied (the cap should be a rate, not a total)

I would put $100 that within 6 months of that, we'll get a post on here saying that their startup is gone under because AWS deleted their account because they didn't pay their bill and didn't realise their data would be deleted.

> (the cap should be a rate, not a total)

this is _way_ more complicated than there being a single cap.

> I would put $100 that within 6 months of that, we'll get a post on here saying that their startup is gone under because AWS deleted their account because they didn't pay their bill and didn't realise their data would be deleted.

The cap can be opt-in.

> The cap can be opt-in.

People will opt into this cap, and then still be surprised when their site gets shut down.

The measures were related to the specific cause of the unintended charges, not to never incur any unintended charges again. I agree AWS needs to provide better tooling to enable its customers to avoid such situations.

>How about AWS implements a hard cap, like everyone has been asking for forever?

s/everyone has/a bunch of very small customers have/

I am never going to use any cloud service which doesn't have a cap on charges. I simply cannot risk waking up and finding a $10000 or whatever charge on my personal credit card.

And for amazon that's probably fine, people paying with personal credit cards are not bringing in much money.

Reply on news.ycombinator.com