AWS CloudFormation

Purpose

It is a recommended best practise in AWS to create a CloudFormation stack for each application per environment or even single instances. Reason include self-documenting and repeatability for those new to the its purpose and design but also allow more thorough inventory of resources by processing stacks. CloudFormation allows upfront architecture review prior to implementation.

The service itself has no costs other than that the stack are stored in S3 but those costs are minimal.

Caveats

Multi-accounts: Currently resources outside the account in which the stacks are created (such as Route 53 in another account) are not accessible in CloudFormation.

All resources referenced in a stack will be deleted when the stack is deleted including a shared resource with other applications. Care should be taken to either using a separate stack for shared resources or reference the entire shared applications as one stack.

Summary

CloudFormation has two parts: templates and stacks. A template is a JavaScript Object Notation (JSON) text file. The file, which is declarative and not scripted, defines what AWS resources or non-AWS resources are required to run the application. For example, the template may declare that the application requires an Amazon Elastic Compute Cloud (EC2) instance and an Identity and Access Management (IAM) policy.

When the template is submitted to the service, CloudFormation creates the necessary resources in the AWS account and builds a running instance of the template, putting dependencies and data flows in the right order automatically. The running instance and collection of resources used by it is referred to as a stack.

Changes to the stack can be made after it’s been deployed by using CloudFormation tools and an editing process that is similar to version control. When a stack is deleted, all related resources are deleted automatically as well.