4
votes

If I have a set of common config like a set of constant used by a number of Lambda functions. Is there any way I can share the data between them in one place so that I can modify the values easily without doing update one-by-one for inside each lambda function?

I can put the data to a DB, but would cause one extra query for each lambda request and run slower.

4
It wouldn't have to cost an extra query for each Lambda request. You could put the query at the module level in your Lambda function rather than in the handler. Then you would only pay the price of the query on startup or if you get swapped out. - garnaat
so I just do the query outside the function and the data will be cached for future lambda call if I didn't get swapped out? - Nick
Yes, that's right. As long as the Lambda container remains warm the query would not be executed again. - garnaat
If you need to update those data files, how would you force a shutdown so that those data files reload? Especially on a hot function that won't swap out? - halt00
Why not use environment variables? - Noel Llevares

4 Answers

4
votes

If the config isn't going to change very often I would just throw it in S3 and have each lambda load it at startup.

If it does change a lot or you want to build some sort of UI to update the settings then you could go the DB route. If you load config when the lambda starts up - ie outside of the handler function you would only need to load the config once as long as the lambda doesn't go back to sleep so the penalty probably isn't that steep.

// this will only be loaded when the Lambda starts up
// keep in mind if you are loading from an external resource
// it will probably be async so your function should return a Promise
var config = someFunctionThatLoadsConfigFromS3();

// entry point for Lambda will be called for every event(api gateway request)
module.exports.handler = function(event, context) {
  config.then(function(config) {
    // do some stuff with config
    context.done(null, 'return a value');
  }).catch(....); 
};
2
votes

You can use Lambda Layers to share code between different lambda functions. The code in the lambda will be then available in each function in the /opt folder.

1
votes

Embedding the configuration in the deployment package offers performance, stability and some cost savings

The process I'm using:

  1. Store the configuration in a file (a git repository perhaps)
  2. Include the configuration file as a dependency in all relevant Lambda functions
  3. Set your build environment to build, test and deploy all dependent functions whenever the file changes

Some benefits:

  1. The functions can be tested together with the new configuration. This is more difficult when the configuration is dynamically loaded
  2. Easy version management: one function version only needs to support one version of the configuration file
  3. Optimal loading time
  4. Price of shared configuration is fixed (as far as I know, there isn't any cost of deploying a function). However, deploying a function takes some time

This is my experience with running various sets of lambda functions at scale for a year. The challenge of doing deployments without down time needs to be solved anyway.

0
votes

Are you using AWS cloudformation to provision these lambdas? If so, you can pass common config variables into your master stack, inherit any necessary items into child lambda stacks, and add them as environment variables

Adding environment variables directly to AWS Lambda cuts down on storage costs and unnecessary calls to AWS storage services.

See this article for implementation across multiple environments