5

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.

Improve this question
6
  • 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. Commented Feb 18, 2016 at 15:16
  • 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? Commented Feb 19, 2016 at 5:49
  • Yes, that's right. As long as the Lambda container remains warm the query would not be executed again. Commented Feb 19, 2016 at 12:10
  • 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? Commented Sep 12, 2017 at 19:18
  • 1
    Why not use environment variables? Commented Oct 7, 2017 at 7:28

4 Answers 4

Reset to default
5

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(....); 
};
Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

How about common functions shared between Lambda functions?
I'm not aware of any way to share functions between Lambda functions other than to make them Lambda functions, too. Lambda functions can call other Lambda functions, of course.
If they are just static helper type functions the best thing to do is publish an npm module and then install that in all of your Lambdas(you will have to upload a zip file with the node_modules dir). If its more like sharing a "service" then I would have them call out to a separate Lambda.
@Ryan great answer, but I am trying to research more into it will probably be async so your function should return a Promise . It seems to me that the code which is in global scope will be run synchronously. Which means that the right approach to load native libs or configuration would be to load them synchronously. I found npm package phantomjs-lambda-pack which assumes synchronicity when installing phantom on lambda upon first execution of lambda. Ideas?
2

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.

Improve this answer

Comments

1

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.

Improve this answer

Comments

0

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

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.