A High-Level Overview of AWS CloudFormation

What is AWS CloudFormation?

• AWS CloudFormation is an AWS-native service focused on Infrastructure as Code (IaC) and is one of the core components of DevOps practices in the context of service deployments into AWS. It is designed to manage AWS-related infrastructure.
• Like other services, AWS CloudFormation is a regional service, while services such as Route 53 are global.

Things to Know About AWS CloudFormation

CloudFormation (also known as CF) is the AWS “Swiss Army knife” service for codifying resources in the AWS cloud. It is a native AWS service that can be used at no extra cost (though this does not apply to the services deployed using AWS CF).

AWS CF excels within the AWS cloud and does not have native integration with other clouds. Using IaC outside of AWS with CloudFormation can be tricky, but AWS Lambda (by building custom resources) can be helpful.

AWS Quick Starts provide a repository of third-party tools and allow you to deploy anything that can be done manually through the Console, including EC2, VPC, Subnet, RDS, etc.

You can write high-level descriptive configuration files using native JSON or YAML formats. Additionally, there is a graphical UI to generate deployments using a drag-and-drop methodology.

CF always knows the state of a given deployment at any time. Deletion protection ensures consistent cleanups, preventing leftover artifacts. However, additions made outside the CF template’s deployment may not be deleted (for example, a deployed service will generate SSM Parameter Store entries that would not be deleted automatically).

Deployment logs are available through CloudWatch. In the case of larger deployments or when trying to find specific logs, AWS Athena can be used to search CloudWatch logs using native SQL.

CloudFormation supports automated rollbacks in case of failures, which helps to:

• Keep the environment secure so that half-ready deployments do not compromise security.
• Keep costs low since a half-ready and non-functioning deployment could still incur expenses.

Nested Stacks

“Nested stacks” use templates as modules. An individual template in a nested stack acts as a silo or block for creating resources and infrastructure. This allows for fully self-contained infrastructure deployments, ensuring that no artifacts are left over during removal.

This simplification allows for easy handover and routing of parameters. Resources can be deployed based on dependencies on other stacks. Change sets enable modifications, changes, and updates to existing deployments (though it depends on the service whether it will be an update or a replacement).

Parameters can be passed through other templates at runtime (both inside and outside a nested stack). AWS SSM can access AWS CloudFormation parameters at runtime for a given stack. Combining AWS AppConfig and/or AWS SSM Parameter Store with AWS CloudFormation creates a powerful configuration management solution.

Re-usable IaC

A best practice is to write templates that are as region-, account-, and availability zone-agnostic as possible. This ensures that:

• The deployment itself will work without hard bindings.
• The code can be reused by others.

CF can be interacted with via the Console, CLI, or API. Consider the capabilities when mixing CF API with automation and ticketing systems.