CloudFormation vs. Terraform

Andreas Wittig – 04 Aug 2017

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. You will learn about the differences between CloudFormation and Terraform during this article.

Before we start, both tools are following 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 bits and parts 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 3rd party services. A shortened list of vendors supported by Terraform: Bitbucket, Datadog, DigitalOcean, Fastly, GitHubm, Gitlab, Google Cloud, Heroku, OpenStack, Mailgun, Microsoft Azure, and New Relic.


Depending on your infrastructure a big or at least small plus for Terraform.

Licence 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 is storing its state on disk. Terraform is offering 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 do support modularizing your infrastructure blueprints.


Handling modules with Terraform is simple. CloudFormation is offering 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 which 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 is providing 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 Update

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.


When CloudFormation fails to modify your infrastructure, it rolls back to the previous working state automatically. Terraform does not support rollbacks out of the box. Either you decide to fix the problem and deploy again, or you have to apply the previous configuration yourself.

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.

Andreas Wittig

Andreas Wittig

Consultant. Entrepreneur. Author. Focusing on Amazon Web Services (AWS) since 2013.

You can contact me via Email, Twitter, and LinkedIn.

Briefcase icon
Work with me
Cover of Rapid Docker on AWS

New book: Rapid Docker on AWS

A rapid way to get your web application up and running on AWS. Made for web developers and DevOps engineers who want to dockerize their web applications and run their containers on Amazon Web Services. Prior knowledge of Docker and AWS is not required.

Buy icon
Buy now
Marbot Logo

Incident Management for Slack

Team up to solve incidents with our chatbot marbot. Never miss a critical alert. Escalate alerts from your AWS infrastructure among your team members. Strong integrations with all parts of your AWS infrastructure: CloudWatch, Elastic Beanstalk, RDS, EC2, ...

Slack icon
Try for free
📚 Rapid Docker on AWS
A rapid way to get your web application up and running on AWS. Learn how to package your application into Docker containers.
Learn more!