A CloudFormation template is a blueprint of the resources in your infrastructure stack and their dependencies. It is the interface between the infrastructure developer and the service itself. What gets defined here becomes part of a stack that CloudFormation will eventually roll out in your AWS account. It is a text file that is consumed by the service to provision resources. When you trigger a CloudFormation deployment, you need to pass a template file as an argument to the CLI command. Within a template, there are several constructs that you can leverage to define your infrastructure components. Let’s go through some of them.
Resources
This is a mandatory sectionof the template that defines the resources that should be created in your AWS account. It also includes the properties that define specific configurations those resources should have. A simple example could be the creation of an EC2 instance, mapped to a particular security group, and using a specific Amazon Machine Image (AMI):
Resources:
TestEC2Instance:
Type: AWS::EC2::Instance
Properties:
ImageId: ami-0834874e33262e665
InstanceType: t3.micro
SubnetId: subnet-0e4f97bea5c50b873
SecurityGroupIds:
– sg-06320d12095603e68
KeyName: test-key-pair
Deploying this template will create an EC2 instance with all the configurations defined under the TestEC2Instance: section. You will notice that most of the configurations reference pre-existing resource identifiers. This meansthat they should be present in the respective AWS account (and region) before you deploy a stack using this template.
Tip
Most of the AWS services are region scoped and you should take special care about the implications this could have. For example, a public AMI available in eu-central-1 cannot be referenced in your CloudFormation template when you’re deploying a stack in another region. Furthermore, AWS ensures that none of your resources transfer data to another region unless they’ve been explicitly configured by the user. You should keep this in mind when you’re working on architectures that need to comply with strict data residency and compliance needs.
Therefore, please keep in mind that hard-coding configurations is not a good design practice as stackdeployments will fail if prerequisites don’t exist. Secondly, it’s difficult to reuse such templates in other AWS accounts and regions. Security, reusability, and modularity should be at the top of your mind when you’re working with them. We will cover some good design practices later in the Best practices for using CloudFormation to define enterprise-grade architectures section.
To ensure reusability and a clean design, CloudFormation offers the capability to use parameters,which can be defined at runtime. This enables dynamic configuration possibilities and simplifies template maintainability.