Using SSM Parameter in CloudFormation: Here is the right way

Hello :), In our last post, we discussed how to create SSM parameters using the CloudFormation template. In this post, we will show you how to use the SSM parameter that we created in the last post in a CloudFormation template.

Please note that, even if you create your SSM parameter manually, It doesn’t matter. You can still use the parameter in a CloudFormation template in the same way as explained in this post.

Don’t want to miss any posts from us? join us on our Facebook group, and follow us on Facebook, Twitter, LinkedIn, and Instagram. You can also subscribe to our newsletter below to not miss any updates from us.

Why use the SSM parameter in CloudFormation?

You might think that CloudFormation already allows you to use parameters. You can either hard code them as default values or pass them dynamically.

Then, why do we even need SSM?

Well, you are absolutely right. However, the ability to store parameters centrally at a place and use them in the template is something which is missing in the above approach.

That’s where the integration between CloudFormation and SSM parameters helps.

In short, It provides below benefits-

• Makes our template reusable/Generic
• Storing all parameters centrally in SSM and using them in the stack makes infrastructure management across the environment hassle-free.
• Can help in separating infrastructure configuration from infrastructure code

Permission

Well, as always I am sharing the permission required to get an SSM parameter.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                ssm:getParameter
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Allow"
        }
    ]
}

The above policy is very permissive. So If you are following the least privilege principle of security, use the below policy instead.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                ssm:getParameter
            ],
            "Resource": [
                "arn:aws:ssm:eu-west-1:123456789012:parameter/WebsiteBucket"
            ],
            "Effect": "Allow"
        }
    ]
}

Have you noticed that we have provided the Arn of the exact SSM parameter? You can provide multiple arn as well if you want to access more than one parameter.

Format of Arn : arn:partition:service:region:account-id:resourcetype/resource

In the case of SSM, it will be below. you just need to replace accountId, region and parameter name as per your requirement.

arn:aws:ssm:region:account-id:parameter/WebsiteBucket

How to use SSM Parameter in CloudFormation?

Finally, We are back to the original point 🙂

To be honest, I found two different ways to use the SSM parameters in cloud formation template.

• Dynamic reference
• Using parameter section

Stay with me to know which among the two is the right way to use SSM parameter in CloudFormation, how and why?

Dynamic Reference

The very first time when I had to use an SSM parameter in a CloudFormation template. I searched in our very own friend Google and got this article from aws.

As a result, I ended up using dynamic references like-

'{{resolve:ssm:parameter-name:version}}'

or to be more specific

  WebsiteS3Bucket:
    Type: 'AWS::S3::Bucket'
    Properties:
       BucketName: '{{resolve:ssm:WebsiteBucket:1}}'

Is this the right way to use it?

Now that’s a good question. (I don’t use this way anymore 😛 )

You might already know that every time you edit your SSM parameter, the version increments by 1.

However, In a CloudFormation template, there is no way to specify latest as the version. This means you should always know the exact version of the parameter you want to reference.

Which doesn’t make sense in the time of automation as per me. I have read somewhere that there is a feature request for this functionality. Let’s see…

Latest Update: You can now reference the latest Systems Manager parameter values in CloudFormation templates without specifying parameter versions. If you choose not to specify the parameter versions in the template, CloudFormation will automatically fetch the latest parameter values from Parameter Store.  

Using the Parameter Section of the template

AWS CloudFormation allows you to use the parameter section of your template to define parameters from the systems manager parameter store such as-

AWSTemplateFormatVersion: 2010-09-09
Description: Template to show SSM parameter uses

Parameters:
  BucketName:
    Type: AWS::SSM::Parameter::Value<String>
    Default: 'WebsiteBucket'
    Description: Bucket Name  from SSM that host website

Resources:
  WebsiteS3Bucket:
    Type: 'AWS::S3::Bucket'
    Properties:
       BucketName: !Ref BucketName

What happens when we use a parameter like the above?

• As soon as you define a parameter type to be one of the SSM parameter types, CloudFormation will actually retrieve the value of that key from the systems manager parameter store and use it.
• If you are referencing an SSM parameter in your template which doesn’t exist, you will get a validation error
• If there are multiple occurrences of a parameter, simply you can reference it everywhere you need

Tell me one thing, have you noticed that, there is no version involved here?

That means, anytime when you are doing any stack operation, CloudFormation will fetch the current value at the time of operation and use it.

If the value of the parameter changes in the parameter store and you want your stack to use an updated value, Simply update your stack and it will use the updated parameter value.

A problem with this approach: You need to rerun your stack or update it every time there is a change in the SSM param. If your template is part of a CICD process, it means even if the source doesn’t change, for the new SSM parameter to take effect you need to rerun your pipeline.

SSM parameter types that you can use.

Lastly, let’s see the different SSM parameter types that are allowed in your template.

AWS::SSM::Parameter::Name
 (retrieves only name)
AWS::SSM::Parameter::Value<String>
 (Gets the value)
AWS::SSM::Parameter::Value<List<String>>
 (List of value)
AWS::SSM::Parameter::Value<Any AWS type>

Which approach to Use?

Now that dynamic reference allows us to fetch the latest without specifying the version, I feel you can go with any of the above ways specified based on your use case.

Conclusion:

Finally, let’s sum up what we did in this post.

You learnt to use the SSM parameter in your CloudFormation template.

Additionally, you saw the permission required to access an SSM parameter. Finally, you also learnt which of the two discussed approaches is better and why.

If you find any issues while using the SSM parameter in your CloudFormation template, please leave a comment below. I would be happy to help.

I hope you liked reading my post. Don’t forget to motivate me by-

• Adding a comment below on what you liked and what can be improved.
• Follow us on
  • Facebook
  • Twitter
  •  LinkedIn
  •  Instagram
• Subscribe to our newsletter to get notified each time we post new content
• Share this post with your friends

Suggested Read:

• Basics Of Cyber Security for Beginners
• Create DynamoDB table using CloudFormation
• Provision ACM certificate using CloudFormation
• Most common cyber attacks in 2020
• Create S3 bucket using CloudFormation
• This is why S3 bucket names are unique globally
• Create API Gateway Custom Domain using CloudFormation
• Things You Should Know about AWS SQS Dead Letter Queue
• Basics of Serverless Computing
• Hello and Welcome to CloudKatha(First Post)