Terraform vs CloudFormation vs ARM

Every major cloud provider built their own IaC tool. AWS built CloudFormation. Azure built ARM templates. Google built Deployment Manager. Then Terraform arrived — and most teams switched. This lesson explains exactly why.

AWS CloudFormation

CloudFormation is AWS's native IaC tool, released in 2011 — three years before Terraform. You write templates in JSON or YAML that describe AWS resources, and CloudFormation provisions them for you.

It is deeply integrated with AWS. New AWS services get CloudFormation support on the same day they launch — sometimes before any other tool. AWS manages the rollback logic for you. If a stack fails halfway through, CloudFormation can roll back every resource it already created. For teams that live entirely inside AWS and always will, it is a reasonable choice.

But the moment you step outside those boundaries, CloudFormation breaks down. Here is what a basic CloudFormation template looks like for the same EC2 server from Lesson 1:

{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Description": "Create a basic EC2 instance",
  "Parameters": {
    "Environment": {
      "Type": "String",
      "Default": "dev"
    }
  },
  "Resources": {
    "MyServer": {
      "Type": "AWS::EC2::Instance",
      "Properties": {
        "ImageId": "ami-0c55b159cbfafe1f0",
        "InstanceType": "t2.micro",
        "Tags": [
          { "Key": "Name", "Value": { "Fn::Sub": "web-server-${Environment}" } },
          { "Key": "ManagedBy", "Value": "CloudFormation" }
        ]
      }
    }
  },
  "Outputs": {
    "ServerPublicIp": {
      "Value": { "Fn::GetAtt": ["MyServer", "PublicIp"] }
    }
  }
}

Compare that to the Terraform version from Lesson 1. Both create the same server. The Terraform version is shorter, reads like plain English, and does not require knowledge of CloudFormation-specific functions like Fn::Sub and Fn::GetAtt. And CloudFormation only works on AWS. Full stop.

Azure ARM Templates

ARM — Azure Resource Manager — is Microsoft's native IaC approach for Azure. ARM templates are written in JSON and describe the resources you want to deploy into an Azure resource group.

ARM templates are notoriously verbose. A template that creates a single virtual machine with a network interface and public IP address can easily run to 150 lines of deeply nested JSON. Microsoft later introduced Bicep — a domain-specific language that compiles down to ARM JSON — specifically because ARM templates were so painful to write by hand.

Here is what a minimal ARM template snippet looks like — just the structure for creating a storage account:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "storageAccountName": {
      "type": "string",
      "defaultValue": "acmestorageprod"
    },
    "location": {
      "type": "string",
      "defaultValue": "[resourceGroup().location]"
    }
  },
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2021-02-01",
      "name": "[parameters('storageAccountName')]",
      "location": "[parameters('location')]",
      "sku": {
        "name": "Standard_LRS"
      },
      "kind": "StorageV2",
      "properties": {
        "accessTier": "Hot"
      }
    }
  ]
}

That is 30 lines of JSON with Azure-specific syntax — [resourceGroup().location], apiVersion, Azure resource type strings — to create one storage account. And like CloudFormation, it only works on Azure.

The Same Thing in Terraform

Here is how Terraform handles the same Azure storage account — using the exact same HCL syntax you already know from the AWS examples:

New terms:

• azurerm provider — the Terraform provider for Azure. "azurerm" stands for Azure Resource Manager. Switching from the AWS provider to the Azure provider changes the resources available — but the HCL syntax and workflow stay identical.
• azurerm_resource_group — in Azure, all resources must belong to a resource group — a logical container for related resources. This is an Azure concept with no direct AWS equivalent.
• azurerm_storage_account — the Terraform resource type for an Azure Storage Account.
• account_replication_type — how Azure replicates your data for durability. LRS is Locally Redundant Storage — three copies within one datacenter, lowest cost option.

# main.tf — Create an Azure storage account with Terraform

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "main" {
  name     = "acme-prod-rg"
  location = "East US"
}

resource "azurerm_storage_account" "app_storage" {
  name                     = "acmestorageprod"
  resource_group_name      = azurerm_resource_group.main.name
  location                 = azurerm_resource_group.main.location
  account_tier             = "Standard"
  account_replication_type = "LRS"

  tags = {
    Environment = "prod"
    ManagedBy   = "Terraform"
  }
}

$ terraform apply

Terraform will perform the following actions:

  # azurerm_resource_group.main will be created
  + resource "azurerm_resource_group" "main" {
      + location = "eastus"
      + name     = "acme-prod-rg"
    }

  # azurerm_storage_account.app_storage will be created
  + resource "azurerm_storage_account" "app_storage" {
      + account_replication_type = "LRS"
      + account_tier             = "Standard"
      + location                 = "eastus"
      + name                     = "acmestorageprod"
      + resource_group_name      = "acme-prod-rg"
      + tags                     = {
          + "Environment" = "prod"
          + "ManagedBy"   = "Terraform"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

  Enter a value: yes

azurerm_resource_group.main: Creating...
azurerm_resource_group.main: Creation complete after 2s
azurerm_storage_account.app_storage: Creating...
azurerm_storage_account.app_storage: Creation complete after 24s

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

The Direct Comparison

Here is every major dimension compared side by side:

The Multi-Cloud Problem

This is the argument that ends the debate for most teams. Modern companies rarely live on a single cloud. They might run their main workloads on AWS, their data warehouse on GCP BigQuery, their Active Directory on Azure, and their DNS on Cloudflare. Plus Kubernetes. Plus Datadog for monitoring. Plus GitHub for source control.

With native tools, you need a different tool for each platform — CloudFormation for AWS, ARM for Azure, Deployment Manager for GCP. Each has its own language, its own concepts, its own way of managing state. Your team needs to learn all of them.

With Terraform, one tool manages all of it. The same engineer who provisions your AWS infrastructure can manage your Cloudflare DNS and your GitHub repositories — without switching tools, without learning a new language, without changing workflow.

When Native Tools Still Make Sense

Terraform is the right default choice for most teams. But there are specific situations where the native tools have a genuine advantage:

Common Mistakes

Practice Questions

Quiz