Backend / IaC / 01_cloudformation_vs_terraform.md

CloudFormation vs Terraform

Updated 3 interview angles 3 min read source
On this page6
  1. What Are They Used For?
  2. Key Differences
  3. The same bucket, both ways
  4. The workflow difference that matters more
  5. When to Use Each
  6. Interview angle

CloudFormation vs Terraform

What Are They Used For?

Both AWS CloudFormation and Terraform are Infrastructure as Code (IaC) tools used to automate the provisioning and management of cloud resources. They help define infrastructure using configuration files rather than manual deployment.

AWS CloudFormation

  • A native AWS service that helps define and manage AWS infrastructure using JSON or YAML templates.
  • Automatically provisions, updates, and deletes AWS resources as defined in a CloudFormation template.
  • Fully integrated with AWS but limited to AWS resources.

Terraform

  • An open-source IaC tool developed by HashiCorp that supports multi-cloud and on-premise infrastructure.
  • Uses HashiCorp Configuration Language (HCL) to define infrastructure.
  • Works with multiple cloud providers like AWS, Azure, and Google Cloud.

Key Differences

Feature CloudFormation Terraform
Cloud Support AWS only Multi-cloud (AWS, Azure, GCP, etc.)
Language JSON/YAML HCL (HashiCorp Configuration Language)
State Management No external state (AWS manages state) Uses a state file to track changes
Modularity Less flexible Highly modular (supports reusable modules)
Custom Plugins Limited to AWS Supports custom providers and plugins
Execution Speed Slower (depends on AWS stack updates) Faster (parallel execution of resources)
Rollback Mechanism Built-in rollback for failed deployments Requires manual intervention
Community & Extensibility AWS-focused Large community with extensive provider support

The same bucket, both ways

hcl
# Terraform: HCL, references are expressions.
resource "aws_s3_bucket" "uploads" {
  bucket = "${var.env}-uploads"
}

resource "aws_s3_bucket_versioning" "uploads" {
  bucket = aws_s3_bucket.uploads.id   # a real reference
  versioning_configuration { status = "Enabled" }
}
yaml
# CloudFormation: YAML, references are intrinsic functions.
Resources:
  Uploads:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "${Env}-uploads"
      VersioningConfiguration:
        Status: Enabled

Two differences do most of the work. Terraform builds a dependency graph from aws_s3_bucket.uploads.id and applies resources in parallel where it can; CloudFormation resolves !Ref and !Sub server-side and is generally slower. And Terraform’s providers cover anything with an API — Cloudflare, Datadog, GitHub, your own — while CloudFormation covers AWS.

The workflow difference that matters more

bash
terraform plan -out=tf.plan   # what would change
terraform apply tf.plan       # exactly that, nothing else

Running plan in CI on the pull request puts the diff in front of a reviewer. The -out file is the point: apply without it re-plans and can act on a world that moved since you looked.

When to Use Each

  • Use CloudFormation if you are fully invested in AWS and want a managed solution with deep AWS integration.
  • Use Terraform if you need a multi-cloud strategy, better modularization, and custom provider support.

Conclusion: Terraform provides more flexibility and multi-cloud support, while CloudFormation is ideal for AWS-native deployments with built-in rollback capabilities.

Interview angle 3

  • “Terraform or CloudFormation?” - Terraform for multi-cloud, a far larger provider ecosystem, and a better module story. CloudFormation for deep AWS-native integration, no state file to manage, and native rollback. Most teams pick Terraform unless they’re strictly AWS and value managed state.
  • “What is the state file and why is it a problem?” - Terraform’s record of the real-world mapping. It must be shared (remote backend), locked to prevent concurrent applies, and treated as sensitive because it contains secrets in plaintext. See OpenTofu and the Terraform licence split.
  • “How do you review infrastructure changes?” - plan in CI on the pull request so reviewers see exactly what will change, with apply gated on approval. The destructive operations in a plan are what review is for.