This post is part of a series of introductory articles related to building AWS services using AWS CloudFormation. You can read about CloudFormation Conditions and the DependsOn attribute in earlier posts

While Parameters are technically optional, they are essential to building flexible CloudFormation templates.

Think of Parameters as variables; they are interpreted by CloudFormation when performing actions on your CloudFormation stacks.

Here’s a simple example of creating a parameter for setting a tag value:

1
2
3
4
5
6

environment:
    Type: String
    Default: development
    AllowedValues:
        - development
        - production

Each defined parameter must have the following components assigned:

• Logical Name: used to label or describe the parameter. When assigning a logical name or ID, use a value that makes sense - you’re going to refer to it later - using References.
• Type: you must assign a parameter type. Types can be simple like Strings, or you can use built-in AWS parameter types.
• Value: each parameter you define in the template must have a value assigned to it. You can do this by setting a default value (like we did above), or you can provide it during the deployment - we typically do this via a CI script.

In addition to the required components referenced above, parameters may also contain several optional properties. For a complete list, have a look at the CloudFormation documentation.

Here are few properties we’d typically include in our templates to help ensure our CloudFormation deployment is successful:

• AllowedPattern: used for String parameters; this property allows you to control data passed into the parameter by supplying a regex expression. A simple example would be to ensure a valid IP address for a subnet CIDR.
• AllowedValues: another property that provides a control mechanism for inputs in a parameter. You could use this to control the EC2 instance type and sizes in a template.

Outside of the custom parameters you define, there are several built-in parameter types included in CloudFormation.

AWS Parameter Types

Typically, used to refer to existing AWS resources - there are AWS parameters for Key Pairs, Security Groups, and Subnets - to name just a few.

You can find a complete list within the CloudFormation documentation.

Here’s an example of using AWS Parameter Types for subnets within a VPC:

1
2

publicSubnet0:
    Type: AWS::EC2::Subnet::Id

SSM Parameter Types

You may want to provide information to a sensitive template - maybe a user name/password combination for an RDS DB Instance. Instead of placing this type of information directly in a CloudFormation template, you could instead refer to key-value pairs stored in the Parameter Store in Systems Manager. Here’s a simple example:

1
2
3
4
5
6

instanceUser:
    Type: String
    Default: '{{resolve:ssm:ms-sql-adminUser:1}}'
instancePassword:
    Type: String
    Default: '{{resolve:ssm-secure:ms-sql-adminPassword:1}}'

Pseudo Parameters

Pseudo Parameters are built-in CloudFormation Parameter types and are a crucial part of building flexible templates. Although these are Parameters, you use them when defining Resources (no reference in the Parameter section).

Pseudo Parameters begin with the prefix ‘AWS:’ and allow for the creation of multi-account, multi-region CloudFormation templates.

Here’s an example of dynamically setting a tag value based on the name of the CloudFormation Stack and the AWS Region.

1
2
3

Tags:
    - Key: Name
    Value: !Join ['-',[!Sub '${AWS::StackName}', !Ref 'AWS::Region']]

You can see a complete list of Pseudo Parameters in the CloudFormation documentation.