Over a million developers have joined DZone.

CloudFormation vs. Terraform

DZone's Guide to

CloudFormation vs. Terraform

This review of CloudFormation and Terraform will help you decide which will work best for your use case by comparing their scopes and features.

· Cloud Zone ·
Free Resource

Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

The most reliable way to automate creating, updating, and deleting your cloud resources is to describe the target state of your infrastructure and use a tool to apply it to the current state of your infrastructure (see Understanding Infrastructure as Code). CloudFormation and Terraform are the most valuable tools to implement Infrastructure as Code on AWS.

I have worked with CloudFormation and Terraform in various projects. Here, we will cover the differences between CloudFormation and Terraform throughout this article.

Before we start, both tools follow a very similar approach.

  1. You define a template (CloudFormation) or configuration (Terraform) describing the target state of your infrastructure.
  2. The tool (CloudFormation or Terraform) calculates the necessary steps to reach the defined target.
  3. The tool (CloudFormation or Terraform) executes the changes.

But what are the differences of both tools?


CloudFormation covers almost all the bits and pieces of AWS. Terraform covers the most important AWS resources as well. But on top of that, Terraform can provision infrastructure at other cloud providers as well as third-party services. A shortened list of vendors supported by Terraform includes: Bitbucket, Datadog, DigitalOcean, Fastly, GitHubm, Gitlab, Google Cloud, Heroku, OpenStack, Mailgun, Microsoft Azure, and New Relic.


Depending on your infrastructure, this results in a big or, at least notable, plus for Terraform.

License and Support

CloudFormation is a service offered by AWS for free. The AWS support plans include support for CloudFormation.

Terraform is an open source project. Hashicorp, the company behind Terraform, is offering support plans as well.

Licence and Support

When already subscribed to an AWS support plan, that might be a plus for CloudFormation. If you prefer open source, that is a plus for Terraform.

State Management

Both tools need to keep track of all the resources under management. CloudFormation is managing its state with so-called stacks. By default, Terraform stores its state on disk. Terraform offers remote state as well, for example, based on S3 and DynamoDB. It is advisable to use remote state when multiple users are working on the same infrastructure in parallel.


CloudFormation manages state within the managed service out-of-the-box, which is a small plus compared to Terraform, where you need to configure remote state yourself.


An infrastructure for a typical web application consists of a lot of resources: VPC, subnets, security groups, Auto Scaling Group, Elastic Load Balancer, to name a few. Specifying all these resources in a single blueprint will cause you headaches when maintaining the system in the future. Using small modules that you stick together as needed is a common approach.

Both CloudFormation and Terraform support modularizing your infrastructure blueprints.


Handling modules with Terraform is simple. CloudFormation offers multiple ways to create modules with different pros and cons. I’d award Terraform with a plus for usability.

Verify Changes

CloudFormation and Terraform do not only allow you to create your infrastructure from scratch automatically. You can use both tools to update your infrastructure later as well. When applying a change to your infrastructure based on changes you made to your blueprint, it is soothing to be able to verify the changes the tool will execute on your infrastructure.

CloudFormation offers change sets that you can use to verify changes. Terraform provides a command named plan that gives you a very detailed overview of what will be modified if you apply your blueprint.

Verify Changes

Terraform presents a detailed and readable summary of the changes that will be applied. That’s a big plus compared to the basic overview CloudFormation provides with a change set.

Wait Conditions

It is useful to be able to add wait conditions to your infrastructure automation from time to time. For example, if you want to wait until a service has been started on a virtual machine. Using wait conditions allows you to wait for signals sent via HTTPS before depended resources are created or updated when using CloudFormation.

Wait Conditions

Being able to use wait conditions is a plus for CloudFormation. Terraform does not support wait conditions.

Rolling Updates

What happens when you change a launch configuration of an Auto Scaling Group within your blueprint? When using an update policy, CloudFormation will perform a rolling update, including a rollback in case of a failure. Terraform does not support rolling updates for Auto Scaling Groups out-of-the-box.

Rolling Update

Supporting rolling updates for Auto Scaling Groups is a plus for CloudFormation.

Handle Existing Resources

Besides using input parameters, there’s no way to access existing resources with CloudFormation. It is also not possible to import an existing resource into a CloudFormation stack. Terraform allows you to import existing resources. On top of that data, providers enable you to query attributes from existing resources.

Exsisting Resources

Handling existing resources is a plus for Terraform.


CloudFormation and Terraform are both powerful and mature tools. Going through the differences listed above will help you to make a decision for CloudFormation or Terraform depending on your use case. Personally, I prefer CloudFormation when the evaluation based on the differences of the tools does not produce a clear winner.

Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.

cloud ,cloudformation ,terraform

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}