Comment by jjoe | Hacker News Reader

Comment by jjoe | Hacker News Reader

Parent Full thread

I combined seconds into 3M, which is roughly 8640 (number of calls a month to keep it in cache) * 300s (timeout set so it stays in memory). My understanding of AWS lambda is that if you keep it up for 300 seconds, you get charged for that much. Because it's #reqs * #secs. Here's the example from the pricing page (with my comment at the end of the Total compute line):

The monthly compute price is $0.00001667 per GB-s and the free tier provides 400,000 GB-s.

Total compute (seconds) = 3M (1s) = 3,000,000 seconds # ( roughly equals to 8640 * 300 ~ 2.6M seconds in the case of this app)

Total compute (GB-s) = 3,000,000 * 512MB/1024 = 1,500,000 GB-s

Total compute – Free tier compute = Monthly billable compute GB- s

1,500,000 GB-s – 400,000 free tier GB-s = 1,100,000 GB-s

Monthly compute charges = 1,100,000 * $0.00001667 = $18.34

View on HN

I don't think the timeout is related to the caching. When your function returns, it is over. The caching is not transparent, I don't know how it works under the hood, but it seems like if you just call it every 10 minutes it stays hot.
Would love an AWS engi to shed some light on this though.

This sheds some pretty good light: https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...
You will wind up with multiple containers in use at once if you have enough traffic so a call to the general pool that is running your Lambda function will most likely only keep one of the containers from recycling.

It looks to me like you're misunderstanding the recommendation here, which is to hit a fast endpoint to ensure that lambda keeps it somewhere in their caches. This is similar to what one might do with Heroku.
The idea is that something like actually distributing the code to a front-line server seems to add to boot time, so if the lambda is not warm, it will be a little slower. If you keep it warm by having at least occasional traffic headed to the server, you're able to avoid this penalty.
If you look above, you'll see someone else did the math for you, and you're actually only talking about 864s of execution time, not 3M.
It also sort of looks like you just pulled up the pricing example which describes 3M requests that take 1s and worked back to it, because when you do the math you describe it works out to ~ 2.5M

Reply on news.ycombinator.com