Lambda cold start when asset sharing

0

Does anyone know if there is any internal optimization for Lambdas that are sharing the asset?

In other words, what is the cache key for the warm lambda?

Is it:

  • Lambda handler version
  • Lambda asset
  • Lambda handler version and asset

The context of my question is trying to:

  1. Share the asset bundle (handler code)
  2. Have the ability to provide granular permissions to the Lambdas, which are used as API Gateway handlers.
  3. And do not want to incur a penalty for doing so.

Was hoping that if I have a single code bundle (asset), and multiple Lambdas using it, it would lead to cold start reduction (asset sharing).

2 Answers
1
Accepted Answer

Lambda uses the function name and version to decide. If it gets an Invoke request for a function:version that it has an idle, sandbox, it will reuse it. If not, it will create a new one, which will cause a cold start.

It doesn't care if multiple functions share the same asset or not.

profile pictureAWS
EXPERT
Uri
answered a year ago
profile picture
EXPERT
reviewed a month ago
  • Thank you, that answers my question!

0

Hi,

I'm not sure if I understand you correctly, but if you mean building a monolithic Lambda function that would handle multiple or all API Gateway routes, note that according to AWS, it is considered an anti-pattern for the following reasons:

  • Package size: the Lambda function may be much larger because it contains all possible code for all paths, which makes it slower for the Lambda service to download and run.
  • Hard to enforce least privilege: the function’s IAM role must allow permissions to all resources needed for all paths, making the permissions very broad. Many paths in the functional monolith do not need all the permissions that have been granted.
  • Harder to upgrade: in a production system, any upgrades to the single function are more risky and could cause the entire application to stop working. Upgrading a single path in the Lambda function is an upgrade to the entire function.
  • Harder to maintain: it’s more difficult to have multiple developers working on the service since it’s a monolithic code repository. It also increases the cognitive burden on developers and makes it harder to create appropriate test coverage for code.
  • Harder to reuse code: typically, it can be harder to separate reusable libraries from monoliths, making code reuse more difficult. As you develop and support more projects, this can make it harder to support the code and scale your team’s velocity.
  • Harder to test: as the lines of code increase, it becomes harder to unit all the possible combinations of inputs and entry points in the code base. It’s generally easier to implement unit testing for smaller services with less code.

Thus, the recommendation is to map a single Lambda function to a single, well-defined task. For more information, take a look to the previously attached documentation, it's really good.

profile picture
EXPERT
answered a year ago
  • Hi @Mikel Del Tio,

    building a monolithic Lambda function

    Not that.

    The idea is to build a monolithic asset file (handlers.js), which can have multiple handlers, and then be used by multiple lambda functions.

    The reason for that is exactly what you have pointed out, in your list of recommendations. I want to avoid all those problems, so I want to use multiple functions, but they are sharing an asset.

    An asset is a code bundle, with several handlers (entrypoints). Since the code is 99% the same across the handler functions.

  • I am very sorry for not having understood you correctly. Theoretically AWS Lambda reuses the execution environment between function invocations, so sharing a monolithic asset file between different functions should have no impact on coldstart. I hope I have understood you this time.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions