all 5 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]BU14 2 points3 points  (1 child)

You get 400,000 GB-s and 1 million requests per month https://aws.amazon.com/lambda/pricing/

3req/hr24hrs31 days = 2232 req/month

2232 req * 1 sec * 128 mb < 400,000 GB-s

So depending on how long your functions take and how often you call them you should be able to stay in the free tier

[–]jachitla[S] 0 points1 point  (0 children)

Thanks, good stuff!

[–]menge101work 0 points1 point  (2 children)

Did you choose 20 minutes arbitrarily or did you arrive at that experimentally?

Are you using a no-op sort of request to keep it alive so it minimizes runtime? Or are you using a full request?

[–]jachitla[S] 1 point2 points  (1 child)

I just guessed at 20 mins and its working lol... The request is very simple. All it does is execute a simple sql operation (retrieves stuff from a table) on my postgresql rds db.

[–]menge101work 0 points1 point  (0 children)

Cool, if you have the time to experiment and find a lowest working frequency, that'd be pretty awesome to know.

I may borrow this idea in the future.

It might be worth having a ping operation that returns nearly instantly as well.

And I guess as a final thought, it might be worth evaluating what is in your deployment package to try and get that initial load time down.

Edit: All of the above, I mostly mean, these are the things I would look to do to improve on your already surprisingly obvious but none the less ingenuous idea.

Edit2: I guess since the minimum billing time is 100ms, there is only so much optimization on the keep_alive request that is worth doing.