Hacker News Reader

Comment by audiometry | Hacker News Reader

Oh me too. That horrible "mythical beasts" tutorial. I thought I removed it, and then each month for the next two months I'd get nailed for 50? dollars or so.

By definition, I don't understand AWS, so figuring out how to turn it off was nearly impossible. AWS "support" didn't exist. Stackoverflow AWS geeks were in high dudgeon that I'd ask the question, "how do i disable this?" and would kill my question. Finally some kind soul did give me the trick to finding the last service to disable.

BTW the tutorial is absolutely useless. Just a thousand different incantations to repeat. No real understanding communicated. Felt more like an ad for myriad services.

0/10 would not recommend.

View on HN

There are consultancies whose entire expertise and premise are advising on AWS billing to companies who already know AWS, so the idea that a newbie should be aware of whatever magical incantation to limit their spend is ludicrous.

That’s not entirely fair. While I’m not going to defend the complexity of billing in enterprise cloud services it’s also not really that hard to set an billing alert in CloudWatch and track spend in Cost Explorer. Sure it requires a little bit of AWS knowledge but you shouldn’t really be using enterprise services like AWS (over other more accessible services like Digital Oceans) if you’re not willing to spend the time learning it; and at an individual level it’s very manageable.

The reason those consultancy firms exist is because billing scales terribly. Once you’re a business using AWS you’d likely have a multitude of projects running across a multitude of departments which need to be billed to a multitude of different customers and internet cost centres. This all needs to be processed by an internal 3rd party financial system managed by non-technical people who wont even know what AWS stands for let alone what it does and how it works. In those situations the problem of billing becomes exponentially more difficult than a one person hobby project.

> and at an individual level it’s very manageable

And yet, we have horror stories of students and even experts being hit by surprise AWS bills.

Although I agree about usage - I never go anywhere near AWS unless someone else is paying for it.

> > and at an individual level it’s very manageable

> And yet, we have horror stories of students and even experts being hit by surprise AWS bills.

They obviously didn’t bother to manage it. But that doesn’t mean it’s not manageable. It takes all of 5 minutes to set up a budget alarm on CloudWatch. It was one of the first things I looked into doing when I set up my own AWS account years ago specifically because I didn’t know what I was doing back then and thus didn’t want any surprises. If I managed it then, then I find it hard to believe others cannot too.

> it’s also not really that hard to set an billing alert in CloudWatch and track spend in Cost Explorer

Billing alerts aren't good enough.

Consider a scenario where you're consulting on someone else's small- or medium-sized project and your bug costs the client a huge amount of money in the middle of the night. Now who pays? Say goodbye to your paycheck or reputation, even though it should have been preventable.

Another scenario: you launch a startup, and a bug empties the bank account and kills the company. If the solution is to just not use things like AWS and GCP (including Firebase, which has no billing cap) when you're getting started, why are they advertised that way?

I think the issue with billing is the same issue you get with OOMs - which services should go down first if we’re out of money? In practice “OOM” (Out Of Money) is even worse than OOM because with Out Of Memory you are just above the available memory threshold, but with Out Of Money you are literally at 0 capacity which means every single service needs to be killed.

The customer should be able to decide.

I’ve built solutions for customers who would prefer an unplanned outage over an unplanned $250k expenditure. Many customers think that I’m a dinosaur for saying it, but if there’s a 2-5 year expected lifetime for something, it’s almost always more cost efficient to use traditional colo or VPS.

Also, operationally it’s possible to have something more than all or nothing. Big companies usually have “Tier-0” services that must be up all costs. AWS is no stranger to complexity - this type of function doesn’t exist because it would cost them money. They probably make 9-figure money from obviously idle services.

If you want your spend to be capped then there’s nothing stopping you from setting a CloudWatch alarm at a budgeted threshold that then scales down your infra.

AWS is like Lego. You’re supposed to build on it to create the behaviour you want

Hum, I don’t know think you understand what I am saying:

If you are out of money, all of your services needs to be destroyed immediately: including all of your database hard disk drives, because every single piece of infrastructure yields some regular cost.

It means that it is NOT going to be “a simple unplanned outage”, it’s going to be more akin to formatting your hard drive with all of your family photos on it.

Pretty certain AWS just finds it easier to sometimes write off costs rather than implement something so radical that customers may be even less happy afterwards.

> Consider a scenario where you're consulting on someone else's small- or medium-sized project and your bug costs the client a huge amount of money in the middle of the night

You can also set alarms that warn you of projected usage.

> Now who pays? Say goodbye to your paycheck or reputation, even though it should have been preventable.

If it’s legitimate usage then I’m not really sure what you’re advocating; are you implying a service being suspended in the middle of the night because a hard spend limit has been hit is somehow better for your reputation?

Or maybe you’re suggesting that it’s not legitimate costs, in which case you’ve set AWS wrong to begin with and thus your reputation probably deserves to be queried.

> Another scenario: you launch a startup, and a bug empties the bank account and kills the company. If the solution is to just not use things like AWS and GCP (including Firebase, which has no billing cap) when you're getting started, why are they advertised that way?

No cloud service operates that way. In that situation you’ll almost always get charges refunded. Even in instances of gross negligence (which would be the case here since for the bank account to be emptied it means you’ve not been watching your spend for more than a month and no business should operate that way)

I do get the points you’re trying to make but I’ve been working with the cloud for some time and have seen plenty of horror stories, all of which were due to gross negligence and most of which were still refunded by AWS as a gesture of good will. They’d much rather have your repeat business than burn their users with bills that cannot be paid.

I spun up an AWS service a year ago (while taking an AWS course I never finished) and haven't been able to find it or turn it off since.

That's $9/month until I disable that credit card, which I might do one of these days.

I thought they'd notice and disable my account after I successfully disputed the charge one time, but the bills just keep rolling in each month.

This might be a bit overreactive, but... I'm building an MVP for a SaaS app and I sure as heck am not going to host it on AWS.

You’re getting an invoice emailed surely? You can sign in with that email and close the account down.

Happy to help you if you need any assistance

Disclaimer: I don’t work for Amazon but I do work heavily in AWS.

AWS "support" didn't exist.

It's been 5 years since I was responsible for anything AWS, but back then at least support was surprisingly good even when spending less than $100 a month. Emails would get answered and I could often get someone on the phone within 24 hours if I needed.

I think it depends heavily on what area you want support for. EC 2 support is generally very good, billing support is reasonable if a bit slow. Support for a lot of their managed services, or media services is beyond useless. All the support engineer does is take your complaint and says they will check with the internal service team. Your ticket will just end up in "waiting for Amazon" state for weeks or months.

Indeed. The best outcome of going to the frequent AWS events is meeting people from AWS who you can actually contact in these kind of situations.

> BTW the tutorial is absolutely useless. Just a thousand different incantations to repeat. No real understanding communicated.

I share this sentiment after going through a lot of tech tutorials and onboardings. And it's not limited just to AWS. I find myself forgetting most of the information I was supposed to learn. I'm trying to be extra mindful and offer additional explanations when I'm writing procedural guides myself, but I still have a lot to improve.

I understand what you feel completely. I actually wasn't even able to complete the tutorial since the commands given would trigger a permission error one way or another. I got charged $50 as well since I wasn't aware that there's still services running. Such a terrible thing to front as a "Getting Started" guide.

Reply on news.ycombinator.com