4 ms·

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 bui

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?

ww520 11y ago
Same worry about the cost. The API gateway seems pretty expensive.
jsprogrammer 11y ago
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?
bpicolo 11y ago
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.
- daviding 11y ago
  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..
- aluskuiuc 11y ago
  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.
  - bpicolo 11y ago
    Yeah, I do use IAM roles heavily, 2fa, etc : )
nostromo 11y ago
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/monitor-charges.html http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/...
- daviding 11y ago
  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).
- impostervt 11y ago
  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 https://news.ycombinator.com/item?id=10024958

ww520 11y ago

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

jsprogrammer 11y ago

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?

bpicolo 11y ago

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.

daviding 11y ago
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..
aluskuiuc 11y ago
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.
- bpicolo 11y ago
  Yeah, I do use IAM roles heavily, 2fa, etc : )

nostromo 11y ago

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/monitor-charges.html http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/...

daviding 11y ago
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).
impostervt 11y ago
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 https://news.ycombinator.com/item?id=10024958