CloudFormation Templates

What are AWS CloudFormation Templates?

As already studied with the AWS CloudFormation you can prepare, model, and set up the AWS resources in lesser time than provisioning the resource costing more time and managing as well as requires more time focusing on the applications that shall run in the AWS architecture. You can easily get started by creating the template where you can simply describe all the AWS resources that you need to provide, such as AWS EC2 instances or AWS RDS DB instances. AWS CloudFormation takes care of all the automatic provisioning and configuration of the setup of these resources. AWS CloudFormation handles all the hassle so that you are not troubled to individually create and set up the AWS resources along with figuring out what's dependent on what.

Now that we have a brief intro on AWS CloudFormation, we will be going into detail on the AWS Cloud formation template for this article. We heard above that it is with the templates that you can easily create and get started with the AWS CloudFormation. When you start using the AWS CloudFormation, it offers its most popular feature called CloudFormation templates as well as stacks. Creating these templates is quite easy and simple to implement where you need to describe the AWS resources with their properties. While stacks can also be created easily where the CloudFormation provisions the resources which you described in the template.

Let us talk about the Template in detail.

An AWS CloudFormation template can be described as a JSON or YAML file where you can mention the resource you want to provide along with its properties. The files can be saved in any extension, like .json, .yaml, .template, or .txt. The templates are used as blueprints for building the AWS resources. Consider an example, where you want to create an EC2 instance with certain properties, manually it can be every time taking and tricky but with the AWS cloudformation template, you can simply define the service as an AWS EC2 instance, with properties like the defined instance type, and block device mappings, the AMI ID, and its AWS EC2 key pair name. Then this template can be further utilized when you are creating a stack in AWS CloudFormation to crate the resource similar to the description in the CloudFormation template.

Below is an example of the CloudFormation template in the JSON and YAML format.

JSON format:

YAML format:

As seen above, various resources can also be specified in a single template where you can configure the resources to work together. Additional capabilities can always be added to the AWS CloudFormation templates to build complex sets of resources that can be reutilized in multiple contexts.

Template Formats

When we talk about the AWS CloudFormation templates, we know that these templates can either be authored in JSON or YAML formats. All the AWS CloudFormation features and functions are supported over for both formats, including in the AWS CloudFormation Designer. Now it is a no-brainer that you should always for the format where you are comfortable as both offer a similar advantage. While with the YAML format, you also get the feature of commenting etc, which you might not find in the JSON formats.

It is recommended not to add # YAML comments in the templates in Designer as the Designer doesn't preserve these comments while it is converting the template to the JSON format. Also, while updating or modifying the template with the Designer, all these comments will be lost. Comments can only be added to the AWS CloudFormation templates that are created outside the Designer.

Below are some examples of how the templates look like with inline comments in the YAML format:

Given below are the JSON and YAML specifications supported by AWS CloudFormation:

For JSON:
The ECMA-404 JSON standard is followed by the AWS CloudFormation. You can visit here for gaining more insights about the JSON format.

For YAML:
The YAML Version 1.1 is supported by the AWS CloudFormation where a few exceptions are kept in mind too. Below given features are not supported by AWS CloudFormation:

• Aliases
• Hash merges
• The binary, omap, pairs, set, and timestamp tags

Template Anatomy

When we talk about template anatomy, we mean how the template looks like. As we studied a template is a JSON- or YAML-formatted text file describing the AWS infrastructure. As seen below, the sample AWS CloudFormation template anatomy along with multiple sections.

JSON Formatted Text File

YAML Formatted Text File

What is a Designer?

Let us discuss what is a designer in the AWS CloudFormation templates. We can define the Designer as a graphic tool that could be used for building, viewing, along with modifying the AWS CloudFormation templates. By implementing the Designer, we can create a diagram of the template resources with the drag-and-drop user-friendly interface. You can also edit the details via the integrated JSON or YAML editor.

As a Designer is an integral part of the AWS CloudFormation console. you can get started with it, you can open the Designer by clicking on Designer by logging into the AWS condole with your AWS credentials. To get started with Designer, you don't need to be an experienced AWS CloudFormation user, then by implementing the AWS CloudFormation Designer you can easily and quickly validate the interrelationship between a template's resources as well as simply modify the templates.

Below is an example of the layout information that the Designer adds as template metadata:

Uses of Designer:
With AWS CloudFormation Designer you a unleash the following benefits:

• Permits the users to view the graphic representations of the various resources in the AWS CloudFormation template
• Simplifies the authoring of the AWS CloudFormation template Easily handled the editing of the AWS CloudFormation template editing.

Walkthroughs

As studied, the AWS CloudFormation templates are the YAML- or JSON-formatted text files which help to explain to the AWS resources what we want to provision or modify and update in the AWS CloudFormation stacks. For creating the AWS CloudFormation templates, we can make use of the AWS CloudFormation Designer or a text editor. By following the below steps you can quickly get started with the test AWS CloudFormation templates via the AWS CloudFormation Designer along with the plain text.

Walkthrough- Implementing the AWS CloudFormation Designer for creating the basic web server can be done as follows:

With the AWS CloudFormation Designer, you can represent the graphical templates which eventually helps to view the resources in that template as well as how they stay connected. To easily modify and make the required changes in the AWS CloudFormation console, you can start using the integrated JSON and YAML editor. We use the AWS CloudFormation Designer for building a basic web server in a VPC with both the components that we shall then save as a template and implement in creating an AWS CloudFormation stack.

With the AWS CloudFormation Designer you can immediately modify the template to include a VPC resource as shown below:

The JSON Snippet:

The YAML Snippet:

You can get a detailed step-by-step guide for the same by following the walkthrough-createbasicwebserver

The output after you have followed the detailed step, you shall have a template similar to: sample-ec2-vpc.template&region=us-east-1.

Template Snippets

The below example will help you understand how to utilize how to declare the different AWS CloudFormation template parts. These snippets can be reutilized as per your needs.

Amazon CloudFront Distribution Resource with An Amazon S3 Origin

Amazon CloudFront Distribution Resource with Custom Origin

Amazon CloudFront Distribution with Multi-Origin Support

Custom Resources

The AWS CloudFormation registry offers multiple benefits over custom resources like:

• Supporting the modeling, provisioning, as well as maintaining the third-party application resources.
• Encourage the CRUDL (Create, Read, Update, Delete, and List) operations.
• Support the drift detection on private as well as third-party resource types.

The registry-based resources do not need to link an AWS SNS topic or a Lambda function for performing the CRUDL operations which are unlike custom resources. With that being said, the custom resources can be used to enable custom write provisioning logic in the CloudFormtion templates. AWS CloudFormation executes anytime we create or update when there are any changes in the custom resource or the delete stacks.

Example of Custom resources:

For defining the custom resources in the templates, you can implement using the AWS::CloudFormation::CustomResource or Custom::MyCustomResourceTypeName resource type. One property that custom resources require is the service token, which defines where AWS CloudFormation sends requests, like the AWS SNS topic. If we consider an example, suppose you want to include any resources that are not at all available as AWS CloudFormation resource types. But this same can be implemented via the custom resources by which you could manage all the related resources at a single stack.

It is mandatory for the custom resources in the VPC to have a allow permit for AWS CloudFormation-specific S3 buckets when you implement the VPC endpoint feature. The response from the custom resources to a pre-signed Amazon S3 URL. When the responses are not sent to AWS S3, AWS CloudFormation also cant receives a response which eventually leads to the failure of the stack operation.

Template Macros

With the template macros, you can enable to perform custom processing over the templates. This ranges from simple transformations such as find-and-replace operations to extensive actions of the entire template macros. The AWS::Serverless transform taking into consideration the entire template is written in the AWS Serverless Application Model (AWS SAM) syntax. This syntax can be transformed as well as expanded into a compliant AWS CloudFormation template. Considering the AWS::Include and AWS::Serverless transforms, which are macros hosted via the AWS CloudFormation. The AWS::Include transform helps to insert the boilerplate template snippets into your templates.

Using Modules

Let's dive into detail and understand what is a module. A Module can be described as a package where you can store all the resource configurations for inclusion across multiple stack templates. This provides a transparent, predictable manageable, and reusable manner to utilize the module. All the common information can be stored and also get retained in the module including the common configuration, expert domain knowledge, compliance, governance, and industry regulation, accepted guidelines along with the best practices as a modular, customizable building block n the stack templates.

Consider that you work in the banking domain and you want to create a module that has all the built-in security groups along with the ingress/egress rules that are following the security guidelines. Then this module can be included in the template so that you can provide secure banking infrastructure in the stack. This also helps you to have rigid control over your send which you might have done while figuring out how VPCs, security groups, subnets, and gateways work. The Module has the capability of offering versioning which helps to follow the latest security guidelines that change over time. With that being said, with every guideline changed a new version of the module could be created incorporating the new changes.

A module can consist of the following listed properties:

• To define the custom values you can use any module parameters whenever the module is utilized.
• More than one resource can be provisioned from the module, in addition to the data associated with their like conditions and outputs.

Modules Example:

The properties of utilizing the modules in the CloudFormation templates are listed below:

Manageability:
When a module is registered, it gets easier to manage it via the CloudFormation registry. These manageable properties include versioning, accounts along with region availability.

Predictability:
It is important for a module to adhere to the schema that is registered in the CloudFormation registry. This helps in predictability where you know, the resources which can get easily resolved once you include that in the template.

Reusability:
The module can be reutilized multiple times which makes it reusable across multiple templates as well as accounts.

Traceability:
With the traceability factor the module in the CloudFormation has the capability to retain the information of the resources which were in a stack and how they were provisioned from a module. This information helps to simply understand the source of resource changes.

Perform ECS Blue/Green Deployments

By implementing the AWS CloudFormation we can perform the ECS blue/green deployments via the AWS CodeDeploy. We define the Blue/Green deployments as a safe way of deployment strategy offered by the AWS CodeDeploy that helps to minimize the interruptions due to the changing application versions. The scenario can be met by creating the new application environment, known as the green environment, with the current application that's serving the live traffic, which we refer to as the blue environment. With these two environments namely, green and blue, you get a time period that allows you to monitor and test the green environment before the live traffic is routed from the blue environment to the green environment which subsequently turns off the blue environment resources.

When you start implementing the ECS blue/green deployments with the AWS CloudFormation for performing, you need to start first by creating a stack template where you could define the resources for both the green as well as the blue application environments. You also need to define the traffic routing along with the stabilization of the settings that you want to be used. Then you need to create a stack from the same template, which helps in the generation of the blue application. AWS CloudFormation helps to create the blue resources when the stack is getting created. For green deployment, the resources don't get created until they are needed.

Some example:

AWS CloudFormation performs the below-listed operations when a future stack update, you start to update the task definition or the task set resources of the blue environment application:

• When all the blue resources are deleted.
• All the required green application environment resources are generated.
• The traffic is shifted depending on the defined traffic routing parameters.
• When the error occurs before the green deployment is successful and finalized, AWS CloudFormation rolls out the stack back to the state before the green deployment got initiated.

Below listed information can be included in the stack template for performing the blue/green deployments on a stack when the AWS CloudFormation is enabled:

• It has been observed that sometimes you end up setting up the stack template for enabling the blue/green deployments before the stack is created. You also get the ability to have the AWS CloudFormation perform the blue/green deployments in the existing stack by adding the mandatory information to the stack's existing template.
• The resource are AWS::ECS::TaskDefinition and AWS::ECS::TaskSet. When a stack is updated, at least one of the ECS resources will be triggered for a blue/green deployment.
• AWS CloudFormation performs a blue/green deployment for initiating a stack update which modifies the properties of the resources requiring the AWS CloudFormation to replace the resource.
• In the template, you have a transform section that invokes the AWS::CodeDeployBlueGreen and for invoking the hook you can have the section AWS::CodeDeploy::BlueGreen.
• It is recommended to have the AWS CloudFormation generate a change set for the green deployment before the stack update is initiated which enables to review of the actual modification that would happen in the stack.

A CloudFormation template for reference is given below:

For more information, you could visit the link: ECS blue/green deployments

Using Regular Expressions

The regular expressions, widely popular as regexes, can be defined in a number of places in the AWS CloudFormation template, like the AllowedPattern property which you can use for building a template parameter. Here, the regexes at AWS CloudFormation are the Java regular expression syntax. The AWS CloudFormation templates implement the JSON syntax where you can specify objects as well as data. You also need an additional backslash for all the backslash characters in the regexes, else the JSON interprets it as escape characters. Like, you need to write as \\e in the JSON template for regexes of \e.