What is Infrastructure as Code and How Does It Work With AWS CloudFormation?

So, what is IaC? A good place to begin the discussion is with the concept of an application “script.” Scripts are a set of commands that are executed by an application and they often save a human operator from having to manually enter values into applications one by one. Scripts are an early form of automation and have been in use since the 1960s.

One can think of IaC as relying on a series of complex, inter-related scripts. These complex scripts are often referred to as “templates.” Templates have a level of intelligence built into them. For example, a template could provision a virtual machine, install MySQL on that virtual machine, verify that MySQL is running, create a user account and then transfer data into the MySQL database. A template, with its built-in verifications, recognizes that it can’t begin transferring the data until the MySQL database has been verified to be running correctly. In fact, if there is an error in the template, the template will stop provisioning and indicate to the user that an error has occurred.

Due to the increasing focus on IaC, many organizations have released IaC tools. These include Red Hat Ansible, Chef, Puppet, HashiCorp Terraform, SaltStack and AWS Terraform. Depending on their circumstances, clients can choose one or more IaC tools. In fact, these IaC tools can often be configured to work together to suit the client needs.

The remainder of this article will focus on AWS CloudFormation as it was purpose-built for managing the AWS environment. 

What are the Benefits of AWS CloudFormation for IaC?

Let’s go back to the concept of IaC as a method of applying application development processes and best practices to the provisioning and deployment of infrastructure. We’re all familiar with the concept of application versions and, with AWS CloudFormation, we can begin thinking about versions of our AWS infrastructure as well.

For those of us without the direct responsibility for deploying infrastructure, we can often have a relatively simplistic view of the process. You spin up an Amazon Elastic Cloud Compute (EC2) instance, install the desired application and you’re done.

In an actual production environment, even this simple scenario involves dozens of choices. What type and size of Amazon EC2 instance should be used? With which operating system? In which Amazon Virtual Private Cloud (VPC) will the EC2 instance reside? Will it be connected to the internet? What EC2 ports must be open so that it may communicate with other EC2 instances? More importantly, what ports should be closed to improve its security posture?

AWS makes it incredibly easy to spin up Amazon EC2 instances. It is far simpler than deploying the same environment in an on-premises datacenter. That said, if 10 AWS Infrastructure Engineers are spinning up 10 EC2 instances, how can we be sure that all 10 EC2 instances meet the desired specifications? Even if processes are well documented, a manual approach leaves open the possibility of human error. People simply forget or make mistakes.

Now imagine that same scenario with the use of an AWS CloudFormation Template. A CloudFormation Template can be thought of as infrastructure “version.” Let’s say the security, application and infrastructure engineers worked together to create a CloudFormation Template which met all the required specifications. If our 10 AWS infrastructure engineers leveraged the CloudFormation Template to launch their EC2 instances, we would end up with 10 identical configurations all following defined and documented processes and specifications.

Let’s explore another common real-world example. Clients often leverage several infrastructure environments. These are commonly referred to as Development, Test, and Production. The Development and Test environments are abbreviated as Dev/Test. In Dev/Test, new applications are developed and tested before being launched in to actual use by end users in the Production Environment (a.k.a., as Prod).

A common challenge is that applications often work well in Dev/Test but “break” when launched in Prod. There can be many reasons for this, but a frequent scenario is that Dev/Test infrastructure is markedly different than Prod environment. Clients leveraging on-premises infrastructure often have a corner of the data center set aside for Dev/Test. These are often a small set of older machines with outdated operating systems and applications. This is so common an issue that “it worked in dev” is a meme.

The reason that on-premises Dev/Test environments are lacking is that they are expensive to maintain. It is often not feasible to have a full fleet of servers that match the client’s Prod environment. AWS and AWS CloudFormation can easily overcome these challenges.

Imagine a scenario in which our engineers have created AWS CloudFormation templates for our Prod environment. When it comes time to deploy a Dev/Test environment, we simply use the same CloudFormation Template ensuring our Dev/Test matches our Prod Environment. In addition to the benefits of consistency across Dev/Test and Prod, clients can spin up their Dev/Test environments as needed. If a client only needs eight hours of Dev/Test, that is all they pay for. Contrast this with Dev/Test in an on-premises data. The client is paying for all the physical and electronics resources of that Dev/Test environment whether they are using it or not.

An additional benefit of leveraging AWS CloudFormation in a Dev/Test environment is that it encourages more frequent testing and faster innovation. Application developers are no longer reliant on out-of-date environments that match potentially outdated Dev/Test infrastructure and don’t need to rely on infrastructure engineers to spin up their Dev/Test environments. This allows the infrastructure engineers to focus on more strategic priorities and for clients to make better use of their skilled workforce. 

How to Get Started with IaC on AWS CloudFormation

Mark Twain wrote that “the secret of getting ahead is getting started.” Fortunately, AWS makes it easy and virtually risk-free to get started with AWS CloudFormation.

If you’re new to AWS, the first step is to set up an AWS Free Tier account. As the name implies, an AWS Free Tier account lets you experiment with select AWS solutions for 12 months at no charge. The great thing about AWS CloudFormation is that it is always free to use, and you only pay for the services you use. Combining the services included within the AWS Free Tier with AWS CloudFormation allows you to learn and experiment with no risk and little or no expense.

Once you have your AWS Account, you can jump right in by reviewing the AWS CloudFormation “Get Started” guide. AWS provides a number of pre-built CloudFormation templates that will allow you to launch your first CloudFormation stack by opening your AWS account and simply pushing a button.

Whether you are new to AWS or a well on your journey, CDW offers a full range of managed AWS Services to support you. Please reach out to your CDW account manager or call 800.800.4239 and say that you would like to discuss your AWS architecture. They will arrange a meeting with one of our AWS-certified solutions architects who help you define next steps for IaC and AWS CloudFormation initiatives.

I hope you’ve found this introduction to IaC and AWS CloudFormation valuable. Best of luck in your IaC and CloudFormation adventures.