(Part 1) Best practices when automating your deployments with AWS CloudFormation

Updated: Nov 13

If you’re automating your workload deployments on the Amazon Web Services (AWS) Cloud using AWS CloudFormation, you can take steps to save time during and after initial development. In addition to saving time, you can prevent your templates from becoming obsolete. In this blog post, I cover some best practices for AWS customers and AWS Partners to follow when developing infrastructure as code with AWS CloudFormation. The post also covers best practices for testing and maintaining AWS CloudFormation templates.





About AWS CloudFormation


AWS CloudFormation streamlines the deployment of key workloads on the AWS Cloud. With AWS CloudFormation, you model and provision all the resources needed for your applications across multiple Regions and accounts in an automated and secure manner. You can use programming languages or simple text files. AWS CloudFormation templates are text files, written in YAML or JSON format, that define the AWS resources to be deployed.


You can integrate automation tools, such as AWS Lambda and AWS Systems Manager, into your AWS CloudFormation templates. With automation tools, you can automate the provisioning of custom workloads on top of the defined AWS infrastructure.

The AWS Quick Start program provides over 170 examples of AWS Partner and AWS native deployments, all of which use AWS CloudFormation templates.


Best practices

  1. Start with existing AWS CloudFormation templates

  2. Create modular templates

  3. Use existing repositories as submodules

  4. Use an integrated development environment with linting

  5. Use parameters to define paths to your external assets

  6. Use the same names for common parameters

  7. Automate AWS CloudFormation testing with TaskCat

  8. Maintain your templates

1. Start with existing AWS CloudFormation templates


When you use AWS CloudFormation to develop infrastructure as code, first check to see if what you plan to deploy has already been developed and shared with the community. Check for your entire solution as well as aspects of it.


For example, look at AWS Quick Starts, which are open-source and available on GitHub. On the AWS Quick Starts home page, you can search the catalog by partner, product, or keyword, and you can filter by common use cases. Also look at AWS Labs, another open-source GitHub organization with a number of sample AWS CloudFormation templates developed by AWS and by the community of AWS Partners and customers.


If you’re building an automated deployment on AWS infrastructure that includes common AWS resources, starting with an existing template can save you hours or days worth of effort. Common resources include Amazon Elastic Cloud Compute (Amazon EC2) instances, Amazon Simple Storage Service (Amazon S3) buckets, Lambda functions, and Amazon Relational Database Service (Amazon RDS) databases.


2. Create modular templates


While you could use a single AWS CloudFormation template to automate a complex deployment, it’s easier to work with multiple smaller templates. For example, let’s take a three-tier web application with the following parts:

  • A highly available Amazon RDS database

  • An Amazon EC2 Auto Scaling group for the application layer

  • An Amazon EC2 Auto Scaling group for the web layer

  • Load balancers for both the application and web layers

If you were to define every part of this deployment in a single AWS CloudFormation template, the template would be large and difficult to troubleshoot. Troubleshooting and iterating would be easier if, instead, you created a template for each of these components. You would have a child template for the database, a child template for the application layer, a child template for the web layer, and a parent template that deploys the child templates in sequence.


Using a modular approach like this, you and others could reuse the smaller templates. For example, you might copy the database template and use it for another web application.


3. Use existing repositories as submodules


Use submodules to take advantage of work that has already been done. Submodules not only save you time during development but also reduce the need to maintain redundant resources.


If you’re maintaining your AWS CloudFormation templates in a GitHub repository, you can import other GitHub repositories as submodules and deploy them from your parent AWS CloudFormation template. To do this, use the git submodule add command.


The Amazon Virtual Private Cloud (Amazon VPC) Quick Start is a good example. If you’re deploying infrastructure that requires a new VPC, you can add the Amazon VPC Quick Start to your repository as a submodule. Either fork the quickstart-aws-vpc repo to your GitHub account or clone it directly from the aws-quickstart account. Then, your parent stack can call the submodule template as a child stack, passing parameters into it to define the VPC. Parameters include the number of Availability Zones to use, whether to deploy network address translation (NAT) gateways, etc.


Other common submodules include the Linux bastion Auto Scaling group, Microsoft Active Directory Domain Services, and Amazon Elastic Kubernetes Service (Amazon EKS).


4. Use an integrated development environment with linting


The amount of time it takes to launch an AWS CloudFormation template varies from a few minutes to several hours. With complex deployments, a developer might make a simple mistake and not realize it until a stack fails late during testing. Discovering mistakes at he last minute can lead to unnecessary frustration and wasted time.


While AWS CloudFormation templates and scripts can be developed with any text editor, working in an integrated development environment (IDE) can improve the process. An IDE can catch formatting mistakes in real time, can display aspects of your code in different colors to highlight them, and can reformat multiple lines of code simultaneously. Most IDEs can incorporate third-party linting tools to ensure that your code is developed correctly for particular applications, including AWS CloudFormation.


AWS CloudFormation Linter (cfn-lint) is an open-source tool maintained by the AWS CloudFormation team. Cfn-lint analyzes AWS CloudFormation templates and checks for syntactic errors. (The cfn in cfn-lint stands for CloudFormation.) By using an IDE with this linter installed, developers can catch errors immediately, reducing development and testing time. You can find cfn-lint plugins for popular IDEs on the CloudFormation Linter GitHub page under Editor Plugins.


31 views
VĂN PHÒNG
LIÊN HỆ
  • Facebook
  • YouTube
  • LinkedIn

Hà Nội

Tầng 2 Tòa nhà Trường Thịnh,

#1 Phùng Chí Kiên, Cầu Giấy.
 

Thành phố Hồ Chí Minh

Tầng 10, Tòa nhà Dreamplex,

#2 Nguyễn Trung Ngạn, Quận 1

Singapore

101 Upper Cross St.

#05-16 People's Park Centre

Nhật Bản

Shinjuku Monolith 19th Floor,

2-3-1 Nishi Shinjuku, Shinjuku-ku

 

Công ty TNHH Quốc Tế OSAM

(+84) 024 22165050.

hello@osam.io

 

9:00AM tới 6:00PM (GMT+7)

Số GCNĐKDN: 0107692699

Nơi cấp: Sở Kế hoạch & Đầu tư Thành phố Hà Nội (06/01/2017)

 

© Copyright 2020 Osam