CloudFormation Pro Tips

3 min read

It has been a while since I did a blog. Sorry about this.

I figured I’d do a quick one to share 3 hot tips I use when undertaking CloudFormation that I’ve learnt over the years from AWS Quickstarts 😉

Tip 1 – prefix parameters and resources

When defining your parameters and resources prefix them.

put a lowercase p and a lower case r in front of them respectively. Then things look a little easier when using REF lookups!

You’ll know if you’re referencing a param or a resource that much easier.

Example:

Parameters:
  pVPCCIDR:
    Type: String
    Default: 192.168.1.1/24
    Description: CIDR for your VPC that hosts the AppStream Bastian Streaming Instances

Resources:
  rVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref pVPCCIDR
      EnableDnsHostnames: true
      EnableDnsSupport: true
      InstanceTenancy: default
      Tags:
      - 
        Key: Name
        Value: !Ref AWS::StackName

Tip 2 – use the AWS Systems Manager when looking up the latest AMI ID

Once upon a time we used to have deploy an AMI and use a custom resource to look up AMI IDs. You may have missed an update in 2017 like I did for the longest time.. Sigh.

https://aws.amazon.com/blogs/compute/query-for-the-latest-amazon-linux-ami-ids-using-aws-systems-manager-parameter-store/

https://aws.amazon.com/blogs/mt/query-for-the-latest-windows-ami-using-systems-manager-parameter-store/

AWS released the SSM parameter store managed parameter to look this up dynamically for you as per the above links.

An example is this:

Parameters:
  pLatestAmiId:
    Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>'
    Default: '/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2'
    Description: AMI ID pointer in SSM. Default latest AMI Amazon Linux2. 

Resources:
  rOutboundProxyLaunchConfig:
    Type: AWS::AutoScaling::LaunchConfiguration
    Properties:
      ImageId:  !Ref LatestAmiId

Start doing it this way 🙂

Tip 3 – Use SSM Parameters and not Output or Output Exports any more to pass info between Stacks / Templates

Whilst Outputs and Exports are good, and had a purpose at one point, SSM Parameters are now where they are at to pass information between related templates. i.e. you may have a Network template that outputs the VPC ID created with it and have that fed into other templates you create from.

Historically you’d have used Outputs, then Exported Outputs. Now we use SSM Parameters as you can use them as a Parameter type and you can also create them by defining them as a resourec.

Reading in a SSM Parameter into your Template is done like something like this:

Resources:
  rMyS3Bucket:
     Type: 'AWS::S3::Bucket'
     Properties:
       AccessControl: '{{resolve:ssm:S3AccessControl:2}}'

For more information refer to: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html

You can create SSM Parameters in your account by using CloudFormation resource type: AWS::SSM:Parameter . However! PRO Tip: You cannot create secure strings doing so. So you will want a central lambda Custom Resource solution to handle creating an encrypted secure string still.

Example:

Resources:
  rBasicParameter:
    Type: AWS::SSM::Parameter
    Properties:
      Name: command
      Type: String
      Value: date
      Description: SSM Parameter for running date command.
      AllowedPattern: "^[a-zA-Z]{1,10}$"
      Tags:
        Environment: DEV

For more information refer to: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ssm-parameter.html

Ok so thats my 3 pro CloudFormation tips for you for now. 🙂

Hope you found this useful.

Paul.