Select Page

CloudFormation: Reduce, Reuse, Recycle – Part 1

CloudFormation: Reduce, Reuse, Recycle – Part 1

As you get more comfortable working with AWS, CloudFormation (CFn) starts to become an integral part of your deployment and environment creation. It allows you to create environments, over and over, as you see fit. The benefit is not only to quickly provision a like-for-like environment for consumption but by using infrastructure as code, you minimize human error. This is huge, especially in publically available services that store data, such as EC2 and S3. The goal behind writing infrastructure as code is to have a repeatable process, which also includes the way you actually use the written code. With CloudFormation, it’s possible to write code in such a way that regardless of who uses it or where it’s used, it just works. Not only does it work but it works the way you need it to for that specific instance and you’re not stuck modifying the code for each use case.

As the title indicates, this will be 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 some Intrinsic Functions to anonymize a template to allow it to run in any region.

To start, check out the first snippet of YAML-formatted code below. Notice that for the subnet creation (PublicSubnet1, PrivateSubnet1, etc) that it specifically calls out the Availability Zone (AZ) as one of the properties. Needless to say, every single time I run this code as part of a CFn stack, that subnet will be created in the exact same region & AZ. For example, PublicSubnet1 will always be created in us-east-2a. While that might work for a specific project, what happens when you want to provision to us-east-1, us-west-1, etc?

Let’s take a look.

To make this property regionally agnostic, we can use an Intrinsic Function built into CFn to make the stack query what region the stack has been deployed in and auto-magically select an available and usable Availability Zone. This “anonymizes” the code and allows us to reuse the code snippet in multiple regions without having to rewrite code specifically for a project.

Look at the code snippet below and compare to what’s above. You can see that rather than calling out a specific region and AZ in the subnet creation, I’ve used the intrinsic function Fn::Select along with the function Fn::GetAZs. Let’s look at what each one of these does and we’ll break it down one level deeper.

  • Fn::Select – this function “selects” a single value from a list of objects by its index value. You indicate which value from the list you want.
  • Fn: GetAZs – as the name implies, this function creates a list of available and usable Availability Zones in a particular region. You can specify the region you want, or in our case, leave it blank to select the AZs in the region the stack has been created.

For each subnet created below, you can see that I’m specifying that I want to put the PublicSubnet1 into the first available AZ, the PrivateSubnet1 into the second available AZ, and the NATSubnet1 into the third by calling out the index number within the Fn:Select function. This is the “- 0″, ” -1″, and ” -2″ beneath the function (remember that indexes start at 0, and not 1).

In short, we’re now telling CFn to grab the list of AZs in the region we created the stack and create the subnet in a specific AZ without having to call out the region or AZ. We can now run this snippet of code in any region without having to modify anything.

In the next post, we’ll go over Parameters. They give us the ability to further anonymize the code and truly make it reusable for multiple projects.

 

 

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.