Injecting Sensitive data as Environment Variables to Lambda Functions


We are used to injecting sensitive environment variables into ECS tasks via Secrets Manager like this but, we are searching for a similar way to do so for Lambda functions and, came across with this post which, seems like a lovely way of doing it. Still, we have a few questions about it:

  1. James Beswick's post is less than 45 days old, so I think there is no out of the box solution for this directly from lambda service, am I right? If so, could this be added as a customer feature request, please? It's so usual that I don't know why it's not yet available.
  2. Does this work for any lambda deployments? I mean precisely ZIP and Docker-based ones as I'm not sure how Layer set environment variables are passed (or not) to a docker container, for example.
5 Answers


If you're using CloudFormation to deploy your lambda functions, you can use dynamic references as per this section of the documentation.

Example using AWS SAM (with some properties omitted for brevity):

    Type: AWS::Serverless::Function
          SECRET_STRING: '{{resolve:secretsmanager:my/secret:SecretString:secretkey}}'
answered 2 years ago
  • sounds like a great option, as we are using CloudFormation... now it's time to test that solution

  • If you use this one, don't forget to use a kms key to encrypt the environment variable, so that no one can read the value (except the function). With SAM or cloudformation, specify "KmsKeyArn".

    Unless you have a good reason, you should retrieve the secret from secret manager inside your function, like MG said (or using the solution provided by James in the blog post). If the secret changes (for example after a rotation), your Lambda function won't be updated and you won't retrieve the latest value...

  • I consider the secrets as part of the contract in a sense. If you want to retreive inside the function, then SSM Parameter Store is a more cost-effective solution. A solution to changing secrets is to version your secrets by adding a version suffix, as suggested by the docs, but it's good that you highlighted that!


A different option for both, Lambda and ECS can be dynamically read from SecretsManager in the code of your application instead of using Environment Variables.

You need to add a policy to IAM Role for Lambda and TaskRole to access SecretsManager. Then you can get the value using AWS SDK.

An advantage of this solution is that even if the secret change, you can refresh it in the app, so you don't need to redeploy the app. It is also more secure because the secret is not visible anywhere in plain text.

A disadvantage is that it can cost more because you will pull the value more often but it can be cached. Example in .net.

Or a more cost-efficient solution with SSM Parameter Store.

profile picture
answered 2 years ago
  • sorry MG, but that's exactly what we don't want to do

  • sure, if it's a better option for you. Then follow advice from Niklas and Jerome :)


I faced the same issue on my lambdas and I chose to use SSM Parameter store Secure Strings instead of Secrets Manager for the following reasons.

  1. Cost. Each secret costs .50 per month whereas secure strings are essentially free (each 10000 decrypts costs .05)
  2. Consolidated storage. I have all my other lambda parameters in the parameter store so everything is in one place.

Now the only env variable I pass to my lambda is the region where the parameters are stored. When the lambda starts, it calls the store and gets everything it needs.

The main advantage of secrets manager is auto rotation of passwords. When the password rotates AWS takes care of updating secrets manager. Using Parameter Store you would need to change the password manually or create a lambda function to update it. This is not a major concern for my use case.

Just one point worth noting. Put your API calls to the Parameter Store or Secrets manager into some type of init function instead of the handler so the API is only called once when the lambda starts instead of every time the handler is called.

answered 2 years ago

If you want to pass sensitive information to lambda, you can't pass this directly as plain text to lambda. This is because your sensitive data will be visible in environment variables section of aws lambda service in aws console.

Instead, you can use either Parameter store or Secret Manager to store the secrets and pass the ARN of the secret as environment variable to AWS Lambda and your lambda can fetch the secret by communicating with respective service.

Please note that your lambda should have necessary role to communicate and fetch the secret. I've written detailed step-by-step guide to do the same here -

answered 10 months ago

You can use either Parameter Store or Secret manager for storing the secret and within your lambda function - you can retrieve the secret dynamically and use that secret accordingly.

I've written detailed step by step guide on how to use this here -

answered 9 months ago

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