CloudFormation

Simplifying CloudFormation deployments using Nested Stacks

A few weeks ago, I talked about the concept of using multiple small CloudFormation templates in a single project. If we keep templates small, they are 1) easier to manage, 2) easier to troubleshoot and 3) less likely to lead to failed deploys after making any updates - because they are easy to understand.

There are two methods of tying CloudFormation templates together - nesting and chaining. In this article, I’ll discuss how you can nest multiple templates to cover all the components of your project.

Protecting resources managed by CloudFormation with a Stack Policy

A CloudFormation stack policy is a JSON document that allows you to control who can update resources deployed via CloudFormation.

In combination with a deletion policy, it provides you with a simple way to protect from accidentally updating a resource during a CloudFormation stack update.

Introduction

Before looking at a simple stack policy, knowing a few key concepts is essential.

First, a CloudFormation stack does not have an associated policy document by default. Therefore, you need to create a stack policy to protect resources in a CloudFormation stack.

CloudFormation changesets - review changes before running a stack update

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

Think of a changeset as a dry-run - or an ‘Are you sure’ pop-up - it provides you with the opportunity to preview changes to AWS resources before you run the stack update.

Here’s a simple example of a generated changeset.

Using a Deletion Policy to protect resources deployed using AWS CloudFormation

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

By default, when you delete a CloudFormation Stack, all resources are deleted (there are some exceptions - check the AWS DeletionPolicy documentation page to be sure). In most situations, this may be what you would like to happen; however, you may have business-critical resources that require an extra level of protection.

Using Conditions in your CloudFormation templates

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

The simplest way to think about Conditions within a CloudFormation template is to treat them like ‘if’ statements in your favourite programming language.

By using Conditions, we’re able to create templates that can be used across multiple environments within our AWS accounts, which results in a lower number of templates to manage - which is a good thing.

Using Parameters in your CloudFormation templates

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