Hacker News Reader

Comment by daviding | Hacker News Reader

I'm playing with these exact things now and it is very enjoyable so far.

My main worry is not on the technical side but on how things are charged for. If I build something that starts to get used I am covered in terms of scalability, but not in a way that protects me from 'cost scalability' so to speak. I know I can set up billing alerts and hit a big 'shutdown' button in response to high load, but what I don't think I can do is throttle these services based on the money I want to budget/spend. With my own services I have a hard cost limit, with a hard scalability limit, or rather I just accept that my response times will go down or fail once I've allocated all I can afford.

If there something for AWS in terms of 'cost throttling'? It may be a gap in their services, especially for people want to build things that might get traction?

View on HN

As a small user, I've bemoaned the lack of 'cost throttling' for a while. I spend minimally and don't want to worry about e.g. private key leaks that cost a fortune, or some malicious traffic hitting my s3 hard.

As a thought exercise it is interesting to think through what we would 'trade' though. For the S3 case there could be a hard cap of allocation, but once it is reached then does the service just switch off? Could it just respond to, say, 100 requests per second, as a ratio of how much money you want to spend in some time period?

For Lambda style services it's odd because if I was hosting them in my own container (or an AWS one even) then they would still accept requests but their responses would start to slow (but still work). Trading through-put for cost/scalability?

The trouble with AWS services for that 'fear of success' type of budgeting (different from losing a key or malicious calls) is they are either on or off, with no in-between cost/latency/resource allocation ratio.

I'm surprised this hasn't come up more actually (or I just missed it), considering the overlap between devs that would like less devops and devs with limited budgets..

One of the easiest mitigations to this is to not even create credentials that have access to do anything that could run up a bill in any short amount of time. Between the Console (access protected with an MFA token) and IAM roles, neither you or your application ought to ever have to handle raw AWS secrets.

Yeah, I do use IAM roles heavily, 2fa, etc : )

The other thing that would be interesting to look at would be the cost of running an alternative implementation on a more standard platform. What would be the cost of running the same application on AWS VM's, for example?

Is Amazon trying to extract a profit? Unless they are using specialized hardware, can they really execute this service any cheaper than you could? Or do they pad the billing to fund Amazon?

Why would I go with a likely much more expensive option (I'd be pretty surprised if Amazon's billings for this service scale linearly with their costs) instead of the option that provides more traditional cost scaling?

You can set up an alert to notify you as soon as your bill exceeds a given threshold.

http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/...

Yes, thanks - I do use those. I was thinking of a slightly different scenario though when compare to my own container, as in my reply to bpicolo below (or above).

The alerts don't work too great. I wrote this in response to a previous story:

"I actually had a billing alert set, and I did get an alert, but it looked like this: "You are receiving this email because your estimated charges are greater than the limit you set for the alarm "awsbilling-AWS-Service-Charges-total" in AWS Account XXXXXXXX. The alarm limit you set was $ 10.00 USD. Your total estimated charges accrued for this billing period are currently $ 1050.95 USD as of Saturday 18 July, 2015 17:34:36 UTC." So, it came a bit too late to take action."

https://news.ycombinator.com/item?id=10024958

Same worry about the cost. The API gateway seems pretty expensive.

Reply on news.ycombinator.com