Hacker News Reader

Comment by themartorana | Hacker News Reader

If you want to play with VPS servers, use DO. If you want to virtualize a data-center or series of globally-connected data centers with racks of servers, use AWS.

So maybe AWS isn't the right solution for you. You say in another comment that warnings about billing overages aren't enough. AWS can't hold your hand and provide Netflix-capable services at the same time.

Amazon chose the latter. I would recommend you not choose AWS until you have the time to dedicate to it.

View on HN

How is being able to set up a $ limit "holding my hand"? You guys are defending something that is indefensible.

I don't want to "play" with VPS servers, I want to work knowing that I won't go bankrupt just because I'm using at the same time a service that won't let me set up a limit, and a pull payment system (ie. credit cards, as opposed to push systems like Bitcoin).

Can you use a pre-paid credit card with Amazon? (Not that that would absolve you of owing the balance - but they might halt your account for lack of payment and prevent further charges from accruing).

AWS charges are monthly so it won't help much (also they don't immediately pull the plug, they send you the email warning first). One just needs to setup the alarms and pay attention when deploying a new code. It sounds far more scary than it really is.

If you don't want to bankrupt yourself then check your usage every day or hour. It's still your responsibility not your vendor's.

Like it or not this is a problem many of us have, and are avoiding AWS for that sole reason. You can keep blaming the victim, or you can accept not being able to set up a limit is a usability problem.

It's like saying "this website is stupid, it's storing passwords in plaintext", and you answering "hurr, it's the user's responsibility to create and manage cryptographically secure passwords".

You're not a victim! Youre inability to control your costs, given the tools, alarms and general common sense doesn't entitle you to some magic off button! Learn to use the tools appropriately and you won't incur unexpected costs.

And as an analogy, Aws is more like C; if you are willing to put the time in to learn, you can do some amazing things that are impossible with other providers. But you must take responsibility for them.

How is a simple configurable limite a "magic button"? What extreme technical difficulties do you see in implementing it, that warranted you calling it "magic"?

Because it would tear down the entire stack? If you're a real business, depending on servers to be up and data to stick around, then it makes absolutely no sense to have machines shut off and volumes deleted if you hit some arbitrary marker. There's nothing you get for free in AWS (besides the Free tier, and not many people are running their entire, highly profitable business on that) and the only solution to "not spend more than $X per month" is to literally shut down and delete things.

I'd love to hear use cases where legitimate businesses, who make money off of the products or services they offer, can literally afford to have their business just stop working. It sounds totally contrived.

A CloudWatch alarm on a billing metric could also be used to send you SMS, email, hell even call you if you want to wire a webhook up to a quick and dirty twilio app (via SNS)

In fact, we use an SNS->Slack gateway running on a free Heroku dyno to get out alerts in a Slack channel (which is pushed to phones/etc), along with other CloudWatch alarms related to performance.

Honestly, this issue of "I don't have any visibility into what I'm spending" is a waste of energy. You do, and you can have AWS bug you as intensely as you want with updates as frequent and as urgent as you need

I imagine that they decided not to have $ limit as implementing that would be once you hit the $ limit, they will take your whole stack down completely. This includes anything you've had setup on AWS, which could be hundreds of instances of any of their services... which may or may not be feasible to do instantaneously or safely (without you losing data or breaking something.) Imagine pulling systems down in the wrong order or while writes or reads are being done... you now have no guarantee that your data will be in a good state.

It's always best to leave termination of your client's systems up to the client than to pull the plug out from under them... at least I'd like to think that's how they would have reasoned it internally.

You can have a $ limit. Use a CloudWatch alarm that shuts down your instances if the billing metric exceeds the growth rate you specify for the period you specify.

It's not "playing": reading is fundamental. Their billing rules are clear. It could be argued that their vocabulary for describing the billing rules takes a bit of figuring out. I have a client that didn't understand either the rules or my instructions and did something silly and ran up a $5000 bill, when he was thinking it would be $100~$200. We called Amazon and they cancelled the bill.

Amazon is very easy to work with, if you simply tell them that you are an idiot and fucked up. You're not the only one.

you could protect yourself by setting up a limited liability company (cost in the uk is about £14), then your assets aren't at risk if something goes very very wrong...

Amazon probably should do a credit check before offering thousands of pounds in credit...

(I am not a lawyer and this should not be taken as legal advice)

Reply on news.ycombinator.com