Setting up and configuring infrastructure in any Cloud provider can be a daunting and complex task. When speaking about AWS specifically, the AWS console will guide you through the steps necessary for each service. However, the console can be difficult to get to grips with, and more importantly, none of the configuration changes you’ve done manually through the console are easily or reliably reproducible. For example, if you needed to create a duplicate of an existing environment for testing or disaster recovery purposes, you’d have to manually go through these steps each time and there’s no guarantee you’ll catch every little configuration detail. Enter Infrastructure as Code (IaC) – the best method to make it possible to represent your infrastructure in a machine-readable document. Codifying your infrastructure through IaC allows you to reproduce the same environment reliably in other regions or accounts. It also allows you to securely store your infrastructure setup in a version control system like GitHub or GitLab which improves reusability of your existing libraries and setups. Storing your IaC templates in a VCS also comes with all the benefits that you’d expect with version controlling your infrastructure, such as an audit trail of who did what and how the infrastructure has evolved. Using IaC gives your DevOps and platform engineers the tools to continuously improve your infrastructure in a more standardised way without getting in each other’s way.
In this blog post, we’ll explore three powerful tools – Terraform, AWS Cloud Development Kit (CDK), and AWS CloudFormation – each with its unique approach to IaC in general, and each differing in their level of integration with AWS. Let’s dive in and see which solution suits your way of working best!
AWS CloudFormation
Launched by AWS in 2011, this is the oldest IaC tool discussed in this post. CloudFormation provides an interface to create infrastructure in AWS through the use of YAML (or JSON) templates that contain all information necessary for your services to be created and integrated. Each CloudFormation template can be customised with specific data for the given environment, stage, or intended goal. Variables like tags, service names, VPC ID, Subnet IDs, environment variables, and many more can be provided simply.
Templates are combined and deployed as a Stack, which is used by the CloudFormation service to deploy your actual resources in the targeted AWS account and region. The CloudFormation interface in the AWS Console then shows you the progress and status of your stacks, and keeps track of the state of the stack and its resources, as long as they’ve been deployed through the CloudFormation service.
Usability
As CloudFormation has been on the market the longest, it’s been tested, hardened, and expanded loads of times over the years. The major downside of the solution is that it’s only usable with AWS, meaning that you can’t support any service outside the AWS ecosystem through CloudFormation. Apart from that, newly created and changed resources that have been processed outside your CloudFormation stacks can cause the stack to drift, an issue where CloudFormation’s expected state differs from reality. Fixing this can be hard for even the most veteran users of CloudFormation. Still, using CloudFormation means that you’ll get an easy-to-use interface for deploying your infrastructure as code, in a format that is easily understood by DevOps specialists, developers, and support teams alike. It applies to nearly every service that AWS offers and is constantly updated by the CloudFormation team to include new and exciting ways of managing your infrastructure as code.
AWS CDK
As the set of available AWS services grew over the years, people were looking for new and improved ways to manage their infrastructure. The AWS Cloud Development Kit (CDK) was introduced in 2018 to provide a more developer-friendly solution to writing infrastructure as code for AWS. It supports multiple high-level programming languages such as Python, JavaScript/Typescript, Java, C#, and more to provide a more DRY (Don’t Repeat Yourself) approach to creating infrastructure. It also allows reusing high-level and low-level components through (third-party) libraries.
CDK represents AWS resources as constructs, each of which can be part of one or more Stacks. These Stacks can be seen as the equivalent of a CloudFormation Stack, as CDK synthesises your code into CloudFormation templates before deploying them to your AWS account(s).
Usability
Although CDK is “just creating CloudFormation templates” during deployment time, it’s a different approach to IaC as it is trying to solve the issue of Don’t Repeat Yourself (DRY); one which is common amongst many more declarative IaC tools. It provides a wealth of built-in and community-made libraries that combine the strengths of programming languages with the possibilities of CloudFormation, and thus provides a great starting point for deploying and managing AWS infrastructure. One weakness we found with CDK is that, like CloudFormation, it is made solely for deploying to AWS. This means that any form of inter-compatibility with other cloud providers or external solutions is impossible. Also, as CDK is using CloudFormation at its base, we see the same issues with possible stack drift that we mentioned previously. Lastly, we’ve found that because CDK is the only solution allowing you to use a multitude of programming languages, usability relies heavily on the skill set available within your organisation. Choosing the right programming language with which to create your CDK projects is vital for proper adoption within the company.
As we’re quite fond of the approach CDK is taking when it comes to IaC, in our opinion, deciding CDK means having a great set of tools available for your IaC needs. Using CDK, you’re backed by CloudFormation and the AWS development team for years to come, and we’ve found it to be an easier entry point for many developers or DevOps engineers with a programming background.
Terraform
Hashicorp released the initial version of Terraform in 2014 and has been providing continuous updates to its solution over the years. This IaC tool uses HCL (Hashicorp Configuration Language) as a declarative “scripting language” and supports AWS, multiple external services, and several other cloud service providers out of the box. As Terraform uses a more declarative approach to infrastructure as code, it uses a different pattern for dividing your code up into smaller, reusable components.
The building blocks of Terraform consist of resources and data sources. A resource contains all information about the actual deployable cloud resource, whilst a data source contains details regarding your cloud environment (e.g. AWS Account ID, AWS Region, VPC ID, Subnets). To prevent DRY, a module system has been added that can combine resources to provide a more straightforward solution for many common patterns, which are developed in open-source communities or available in the publicly available Terraform registry.
Usability
Using Terraform means having access to resources within and outside of AWS. This is a great solution for managing a multi-cloud setup, or when your company will eventually need external services that aren’t provided by AWS. Because Terraform uses a specific scripting language (HCL), it might be harder for employees with a developer background to adjust to the toolset. One of the other downsides might be that Terraform is quite generic, which means updates to AWS services or specific use cases might not be covered fully. Still, we’ve found Terraform to be a great solution for most use cases or for companies that aren’t solely focussing on supporting AWS through IaC. Using a tool such as Terraform which can cover multiple cloud providers and third-party services means that you can manage all these resources from a single tool, allowing you to diversify across providers without adding complexity.
Conclusion
Whichever tool set you go for, IaC is a solution to a problem that plagues many companies. Having a reusable setup that contains all your infrastructure, manages it properly, and makes it possible to recreate an entire environment within minutes makes changes to your infrastructure possible without the fear of environments drifting apart. Another great side effect of an IaC tool is having the ability to create a test environment that mirrors your production or staging environments. This makes (stress) testing much easier and more efficient.
Having said that, choosing a tool set can depend heavily on the resources and skills that are currently available in your company. Terraform might be used more easily by DevOps specialists and system administrators, whilst CDK and CloudFormation are more heavily relying on programming paradigms that are more suited for employees with a background in development. In our experience, none of the discussed solutions are better than others; they merely differ in usage patterns, your specific use cases, and what your employees feel most comfortable with.
Still don’t know which IaC tool to go for when developing for AWS, or would you like to have a meeting about IaC tools in general? Devoteam is an AWS Premier partner with a proven track record in DevOps, platform engineering, and cloud architecture. If you’d like to know more about how we can help you in your Cloud journey, reach out at the link below.