Select Page

CloudFormation: Reduce, Reuse, Recycle – Part 2

CloudFormation: Reduce, Reuse, Recycle – Part 2

This is part of a multi-part blog post in which I’ll dissect a basic CloudFormation template that I wrote to make it reusable, regardless of what client/project you’re working with or what region in which you’re creating a stack to run. In this post, I’ll be discussing how to use Parameters to further anonymize a template to allow reuse and ultimately help you reduce the number of custom templates you need to accomplish a set of tasks.

In the previous post, we discussed how to remove regional/AZ specific information to enable the same code to work in any region. However, there are still values hard coded within the template which doesn’t make it reusable in all cases. For example, take a look at the code snippet below. What if this VPC of overlaps with my on-premises IP space or another VPC I wish to peer with? Maybe we don’t want every public subnet we provision to be called PublicSubnet1 or I want the stack to assign the name a unique value? If any of these are true, I’d have to modify the code for each use case, exactly what we’re trying to avoid.

Enter Parameters. Let’s talk about what they are first.

Parameters are input values that are passed to a template as value pairs to create AWS resources. Parameters are declared in the Parameters section of a stack template and are a completely optional section of a template (notice above that there is no Parameters section, only a Resources section). Parameters are akin to declaring a variable in a traditional development language.

Parameters can be defined as a string, number, CommaDelimitedList, or an AWS-specific type. Within a parameter, there are a variety of Properties that can be used as well to ensure data validity, declare a default value, or just a simple description.  The only required property of a parameter is “Type”.

Now that we know what they are, let’s take a look at what to use them for. As mentioned above, we want to create reusable code, therefore it doesn’t make sense to hard code a subnet’s IP range, or even the name of the subnet within the template. We want to pass this information when running it so it’s customized to do what we need it to do for that particular instance.

Take a look at the code below and see how I’ve added Parameters (within the newly created Parameters section) to the template. You’ll also notice where I’ve replaced the subnet’s IP address and name with a reference to the input Parameter in the Resources section. Take notice of the “Default Value” I’ve added to the “VPCName” parameter as well. If a Parameter is declared but isn’t passed a value, it’ll use the default value during creation. By the way, I purposely left the NATSubnet1 so you can easily see the comparison.

Let’s see it in action.

Using the AWS Console, you can deploy the new template and manually enter the values for the Parameters we declared above, as shown below. You’ll notice that it has pulled both the Parameter name and description in the Stack creation wizard. What’s even more powerful is passing these parameters to the template in an automated fashion, maybe from something like ServiceNow Orchestrator or VMware vRO. The values could be derived from defaults you’ve decided upon or they could be gathered from a form the requester submits. Either way, it’s a useful way to deploy immutable and/or repeatable infrastructure on AWS.

As you can see from the latest code snippet, the template looks quite different from the original. Not only can we reuse this template in any region but we can reuse the same code while creating VPCs and subnets with different IPs and names as required. This will further assist us with the reuse of the same code for different projects.

The next post we’ll look at how to use the Fn::FindinMap Intrinsic function to see how we can add EC2 instance deployment to our template and ensure that the template continues to be regionally agnostic.


About The Author

Bryan Krausen

Bryan Krausen is currently working as a Technical Architect with experience in a vast number of platforms. Bryan has been active within the VMware vExpert community for several years and is the leader of the Louisville VMware User Group (VMUG) and Louisville AWS User Group.

Leave a reply

Your email address will not be published.