Using AWS Parameter Store with AWS Lambda
July 5, 2022
TLDR: In this article, we go over how to use Parameter Store in an AWS Lambda Function to read configuration parameters.
Parameter Store
There are a couple of ways one could share configuration parameters across different parts of their infrastructure on AWS.
Following are just a handful:
- AWS Secrets Manager
- AWS Systems Manager (Parameter Store)
- Environment variables
Depending on the specifics of your infrastructure, using environment variables may be a no-go.
In some cases, you might want to be able to dynamically share credentials automatically across configuration management platforms. For example, if you might have split up your infrastructure management across different tools - say you use some centralized Terraform to manage a database, and you use AWS SAM to manage some serverless stack that needs to connect that database.
Parameter Store v. Secrets Manager
Parameter Store is a key-value store that is part of AWS Systems Manager (AWS SSM). It is used to define whatever parameter may be needed in your system. That could be database credentials, third-party API keys, or whatever else. Values in Parameter Store can also be encrypted.
Secrets Manager on the other hand is focused on credentials. It offers a couple of secret-specific features such as the ability to generate random values using the AWS SDK or the ability to rotate secrets on a schedule.
At the time of this writing, Secrets Manager is a paid service charged $0.05 per 10,000 API calls, while Parameter Store is free of additional charges.
If all you need is to store credentials somewhere and you have no intention of using the advanced features of Secrets Manger, then Parameter Store is probably the right choice for you.
Setting parameters in Parameter Store
You can set your parameters in the Parameter Store manually, or you can do it with some infrastructure as code (IaC) platform such as Terraform.
Setting parameters manually
Doing it manually is easy. You just need to head over to the Parameter Store in the AWS Console. You create a parameter, give it a name, choose , and you put your value inside the textarea.
The typical way of using Parameter Store is to create one parameter for each value you want to store - although you could also squeeze multiple with a on each line.
In the case of database credentials, you could define the following parameters:
Although nothing is keeping you from defining a single parameter named something like and shoving all the data in there by setting something like this as the value:
Using Terraform
If you are using Terraform or some other IaC tool to manage your infrastructure or part of it, you might want to instead set the parameters directly from there as part of the relevant deployment.
If you are managing a database deployment in Terraform for example, you might want to generate random credentials on the fly and put them into Parameter Store directly from there without having to manually copy and paste them around.
Here's an example of how you would do that in Terraform.
Your database resource would use the same credentials in its configuration block.
Reading from Parameter Store in a Lambda function
You are all set up now as far as Parameter Store is concerned. All you need to do now is to read those parameters from within your application code.
This code example is in Golang but the same idea could be used for whatever other language you might be using.
To use this in production, you would probably want to make it testable and improve this horrendous error handling.
Your parameters would also probably have to be environment-specific. You could easily handle that by adding an prefix to each of your parameter. For example instead of .
Here's the project structure for our example:
First, let's cook up a convenience wrapper around the Parameter Store client:
Let's cook up another wrapper around the configuration.
On to the handler. This is the entry-point into the Lambda function. We create our configuration instances outside of the handler so that they are reused on subsequent invocations (on the same underlying Lambda instance).
The calls to the ParameterStore add overhead to the Lambda function on cold start. Once your function is warm, no additional overhead is incurred, but that too comes with the caveats of cold start.