Template strategy for AWS CloudFormation

Brett Gillett

Over the last while, I’ve written quite a bit about the technical side of building flexible and reusable CloudFormation templates. However, I want to discuss something more difficult in this article - your template strategy.

As is the case in most situations, the technology side is ‘easy.’ Processes are entirely different.

You may think it’s easier to start with a simple strategy - everything in one giant, hard-to- understand/troubleshoot template - however, you should consider this an anti-pattern.

Let’s all agree you want to avoid going down this path. Instead, let’s approach templates like we would when designing a modern application. We’ll create small, focused templates and then connect them to build our entire solution.

The analogy I like to use when thinking about template strategy is a restaurant menu. A typical restaurant menu contains many options. You pick and choose items based on any number of criteria. So let’s build our CloudFormation templates like they’re menu options in your favourite local restaurant.

Use the menu strategy for your CloudFormation templates

Here’s an example. You need to build an EC2-based, public-facing web application with a relational database in the backend. Here’s just one way you could break that into small components:

  • IAM: This template contains any IAM-related resources you need. It may have IAM roles, EC2 instance profiles, etc.
  • KMS: A template that defines our KMS keys and policies.
  • VPC: This template defines all the network-related resources for your project - subnets, routes, VPC-connectivity, endpoints etc.
  • Security Groups: This template contains all the security groups you’ll require to deliver your solution.
  • ACM: We’ll define our SSL certificate(s) in this template.
  • ALB: A template that defines your Load Balancer, listeners and target groups.
  • ASG: In this template, we’ll define our EC2 and Autoscaling requirements.
  • EFS: A template that defines our shared file system.
  • CloudFront: In this template, we’ll define our Content Delivery Network.

I know what you’re thinking - that’s a lot of templates for a relatively simple solution - and you’re right. However, you have to remember that by breaking your solution up as I did in my example, you end up with smaller, easier to maintain, more flexible templates that you can reuse across multiple projects, tying them together in different combinations.

There may be a bit more work up front, but you’re setting yourself up for more streamlined future deployments over the long term.

We have two strategies to tie these templates together - nested or chained stacks - but we’ll save that for another post.

Brett Gillett


Like what you read? Why not subscribe to the weekly Orbit newsletter and get content before everyone else?