Table of contents
Open Table of contents
If a lambda has not been run in a while, a pending request needs to wait for it to be initialized. This could take few seconds, depending on the runtime and initial loads.
Functions with less RAM have slower CPU speed
This one perhaps should be obvious, given that it’s listed in the pricing guide (“you choose the amount of memory you want for your function, and are allocated proportional CPU power and other resources”). But from what we’ve seen around the web, this facet of Lambda still trips a lot of people up.
Cloudwatch Costs Money
When you get heavily into Lambda-based development, you’ll become acquainted with Cloudwatch quickly, since it’s the only way (besides rolling your own log solution from scratch) to get a granular record of what Lambdas are running, how many times and for how long — sort of important information.
Empty Event Loop
context.callbackWaitsForEmptyEventLoop = false;
In some circumstances it might be useful to force this value to be false to make sure that the lambda quits as early as possible in case of warmup. Or if you have created a database connection in a previous middleware, this might be hanging and keeping you lambda active until timeout.
Running Out of Time Can Be Hard to Debug
All Lambdas have a time limit for their execution (defaults to 30 seconds, configurable up to 15 minutes). But it can also be difficult to diagnose when a function is hanging, because Lambdas that go over their limit simply disappear — there’s no way we know of to throw an exception which would be trapped by our error alert system. You’re stuck looking in Cloudwatch again for Lambdas whose execution time matches your configured time limit.
Executing a Lambda From Another Lambda is Slow
There may be two cold starts in worst case.