Originally published at https://thomasstep.dev/blog/parameter-store-and-cloudformation
Lately, I have been playing around with AWS SSM Parameter Store, and I have found a fun way of creating and referencing parameters through CloudFormation.
Parameters help me stay organized throughout different environments by unifying all of my CloudFormation "variables" in one place.
I populate my parameters based on the environment I am in and then use those parameters in other templates that create infrastructure.
Of course doing this means that order matters; the Parameter Store CloudFormation template needs to be run before templates that reference those parameters.
I create all my stacks through CodePipeline, so I can define the order that they are created and updated, which means I always know my parameters are present before I use them in subsequent templates.
The strategies that I use can also be applied outside of CI/CD using CodePipeline as long as you make sure that your parameters template runs before you reference them in other templates.
The first example I want to walk through is populating parameters based on environment.
The way I like to go about doing this is with CloudFormation Mappings.
AWSTemplateFormatVersion: 2010-09-09
Description: Adds parameters to systems manager
Parameters:
AWSEnvironment:
Type: String
AllowedValues:
- dev
- preprod
- prod
Mappings:
Environment:
dev:
DBHost: "https://dev.db/"
.
.
.
preprod:
DBHost: "https://preprod.db/"
.
.
.
prod:
DBHost: "https://prod.db/"
.
.
.
Resources:
AWSEnvironmentParameter:
Type: AWS::SSM::Parameter
Properties:
Name: /awsEnvironment
Description: Current AWS environment
Tier: Standard
Type: String
Value: AWSEnvironment
LogFirehoseParameter:
Type: AWS::SSM::Parameter
Properties:
Name: /dbHost
Description: Database Host
Tier: Standard
Type: String
Value: !FindInMap [ Environment, !Ref AWSEnvironment, DBHost ]
Hopefully it is easy enough to see what is happening here.
Under Mappings
I am predefining the values for my parameters.
You can add as many mappings as you would like, which is what I was attempting to show with the extra .
s.
Next up is showing how to use the parameters we just created in other CloudFormation templates.
AWSTemplateFormatVersion: 2010-09-09
Parameters:
Env:
Type: AWS::SSM::Parameter::Value<String>
Default: /awsEnvironment
DBHost:
Type: AWS::SSM::Parameter::Value<String>
Default: /dbHost
Resources:
MyLambdaFunction:
Type: 'AWS::Lambda::Function'
Properties:
.
.
.
Environment:
Variables:
NODE_ENV: !Ref Env
DB_HOST: !Ref DBHost
The parameters from Parameter Store are passed into the Lambda CloudFormation template like any other parameters; however, the Type
and Default
properties of the CloudFormation parameters matter here.
The Type
is telling CloudFormation that the parameter input will be a value from SSM Parameter Store instead of a value that the user gives.
The Default
property is giving CloudFormation the name of the parameter from which we want to pull a value.
The name here needs to coorespond to the Name
property of the parameter in the Parameter Store template.
I prefer to use a Default
property here instead of passing (manually or otherwise) the Parameter Store name, so I never have to worry about what parameter the value actually came from since it is defined in my template.
After you define the CloudFormation parameter, you can use the value like normal.
In this example, I am passing the DB Host I set in Parameter Store to my Lambda as an environment variable.
Now, if you ever need traceability into where a certain environment variable value came from, you can reference back to your templates, which can be version controlled.
Like I said before I use this in conjunction with CodePipeline, which I think is a match made in heaven.
My CodePipeline instance picks up my templates from a GitHub webhook that fires off at a push, builds the parameters stack, and updates the lambda stack.
I can add parameters and then reference them in a template, and after a simple push, they show up in AWS.
Top comments (3)
It's almost 100% AWS Parameter Store. I can't figure out why everybody is simply ignoring AWS AppConfig.
AppConfig doesn't integrate with CloudFormation like Parameter Store?
I actually have not looked into AppConfig before but thank you for bringing it up!