Hacker News new | past | comments | ask | show | jobs | submit login

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




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: