CloudFormation vs Terraform

By Kokil Thapa | Last reviewed: September 2026

You need repeatable infrastructure, not another late-night console session. The CloudFormation vs Terraform debate sits at the centre of that decision for teams shipping on AWS, and often beyond it. Both tools turn servers, networks, and databases into versioned code. They differ sharply in scope, state handling, and day-two operations. This guide compares them the way a production engineer would—using real templates, real trade-offs, and the constraints small teams in Nepal and worldwide actually face. If you are new to IaC, start with our practical Terraform infrastructure-as-code guide for baseline concepts that apply to both tools.

What is the difference between CloudFormation and Terraform?

Both tools implement infrastructure as code (IaC). You declare desired resources in files, commit them to Git, and apply changes through automation. The execution model and ecosystem diverge from there.

AWS CloudFormation is a first-party AWS service. You write YAML or JSON templates. CloudFormation creates a stack—a living record of every resource in that deployment. AWS stores stack state internally. You never manage a state file yourself.

Terraform is an open-source tool from HashiCorp (with the OpenTofu fork as an alternative). You write HCL configuration. Terraform calls provider APIs directly. It maintains a state file that maps your config to real resource IDs. That state is your responsibility—or your platform team's.

A minimal CloudFormation template defines an S3 bucket:

AWSTemplateFormatVersion: '2010-09-09'
Description: Static assets bucket
Resources:
  AssetsBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
Outputs:
  BucketName:
    Value: !Ref AssetsBucket

The Terraform equivalent uses the AWS provider:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

resource "aws_s3_bucket" "assets" {
  bucket = "my-app-assets-prod"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "assets" {
  bucket = aws_s3_bucket.assets.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

CloudFormation syntax is verbose. Terraform HCL reads cleaner for most developers. CloudFormation wins on zero setup inside AWS. Terraform wins when the same patterns must run on multiple clouds. For AWS-only fundamentals, see our AWS CloudFormation fundamentals walkthrough.

When should you choose AWS CloudFormation over Terraform?

CloudFormation is the right default when your entire footprint lives on AWS and you want the simplest operational surface.

AWS-only shops with no multi-cloud plans

If every resource—VPC, RDS, Lambda, CloudFront—sits in AWS accounts you control, CloudFormation removes an entire class of problems. There is no remote state bucket to secure. No state lock table to monitor. No risk of a corrupted local terraform.tfstate file leaking into Git.

AWS also ships same-day support for new services. When AWS launches a feature, CloudFormation resource types often follow within weeks. Terraform provider coverage lags by days or months depending on community demand.

Teams already deep in the AWS console

CloudFormation integrates natively with CloudWatch, StackSets, Service Catalog, and IAM. Drift detection runs from the console or CLI without third-party tooling. Stack policies can block destructive updates on production resources—a built-in guardrail Terraform handles through external policy engines like Sentinel or Checkov.

Regulated environments favouring vendor-managed state

Some compliance frameworks treat vendor-managed infrastructure records favourably. CloudFormation stacks are authoritative AWS objects with CloudTrail audit logs. You do not maintain a separate state artifact that could desync from reality.

On a production Laravel deployment I maintain, the application runs on EC2 behind an ALB with RDS MySQL. The underlying AWS networking could be CloudFormation-managed without touching application code. That separation keeps Linux server administration and IaC concerns in distinct layers—a pattern that scales well for client projects with small ops teams.

How does state management compare in CloudFormation vs Terraform?

State is the sharpest practical difference between the two tools. Get it wrong and you get duplicate resources, orphaned volumes, or failed applies.

CloudFormation: stacks as living state

When you run aws cloudformation create-stack, AWS records every resource ID inside the stack. Updates are diffed against that record. Deletes remove tracked resources—unless you added retention policies.

Drift detection compares the live stack against the last deployed template. AWS documents this workflow in the CloudFormation resource management guide. Importing existing resources into a stack is supported, though the process is more rigid than Terraform import.

Terraform: explicit state you must protect

Terraform writes resource mappings to a state file—JSON that links aws_s3_bucket.assets to arn:aws:s3:::my-app-assets-prod. Local state works for solo experiments. Production teams use remote backends.

A typical S3 backend with DynamoDB locking looks like this:

terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/network/terraform.tfstate"
    region         = "ap-southeast-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

State locking prevents two engineers from applying simultaneously. Encryption protects sensitive outputs. Our guides on managing Terraform state safely and remote state on S3 with locking cover the full setup.

CloudFormation change sets provide a preview similar to terraform plan. They are less readable for complex templates but serve the same gatekeeping purpose in CI pipelines.

Drift: both tools detect it, neither auto-heals silently

Manual console edits create drift. CloudFormation drift detection flags resources that differ from the template. Terraform plan shows differences on the next run. Neither tool silently reverts manual changes—you must apply intentionally. See Terraform drift detection strategies for Terraform-specific patterns.

Which tool is better for multi-cloud infrastructure in 2026?

Terraform wins multi-cloud by design. One HCL codebase can provision AWS EC2, Cloudflare DNS, and a PostgreSQL 18 instance on a VPS—all in one apply graph.

CloudFormation cannot leave AWS. If you need Azure or GCP resources, you add a second tool anyway. That hybrid reality pushes many teams toward Terraform from the start.

For teams evaluating beyond these two, our Terraform vs Pulumi vs OpenTofu comparison covers the broader IaC landscape. OpenTofu matters in 2026 because it preserves the Terraform workflow under a truly open licence after HashiCorp's BSL change.

Reusable modules matter at scale. CloudFormation nested stacks work but feel clunky compared to Terraform modules published on the public registry. Our Terraform modules guide shows patterns you can port conceptually to nested stacks. Terragrunt adds DRY layering on top—see keeping Terraform DRY with Terragrunt.

On booking platforms like Adventure Third Pole Trek, infrastructure spans application servers, CDN, and managed databases. Terraform often provisions that base layer while Laravel handles business logic—a clean split that enterprise application development teams replicate across client projects.

How do you run CloudFormation and Terraform in CI/CD pipelines?

IaC without CI/CD is just expensive documentation. Both tools fit Git-based workflows, but the pipeline steps differ.

CloudFormation in CI/CD

A typical GitLab or GitHub Actions pipeline validates the template, creates a change set, waits for human approval on production, then executes the change set.

1. Run cfn-lint against the template for syntax and best-practice checks.
2. Upload the template to S3 if it exceeds the inline size limit.
3. Call aws cloudformation create-change-set against the target stack.
4. Review the change set output in the pipeline log or Slack notification.
5. Execute with aws cloudformation execute-change-set after approval.

StackSets extend this to multi-account AWS Organisation deployments—a native feature Terraform lacks without custom wrappers.

Terraform in CI/CD

Standard pipeline stages: init, validate, plan, apply. Store plans as artefacts. Require approval before apply on production workspaces.

terraform init -backend-config=backends/prod.hcl
terraform validate
terraform plan -out=plan.tfplan
terraform apply -auto-approve plan.tfplan

Never run apply without a saved plan in production. Plan files pin the exact diff that apply will execute. Our Terraform CI/CD with GitHub Actions article walks through a complete example. Scan plans with Checkov for Terraform misconfigurations before merge.

I've maintained sister legal-tech sites on a shared Deployer 7 pipeline. The EC2 hosts could be CloudFormation-provisioned while Deployer handles zero-downtime Laravel releases. That two-layer model—infra tool plus deploy tool—is common on projects documented in our CloudFormation on AWS guide.

Policy, cost, and testing

Both ecosystems support policy-as-code. CloudFormation Guard (cfn-guard) validates templates against rules. Terraform integrates with Checkov, tfsec, and native check blocks in recent versions. Run policy checks in CI before any apply reaches production.

Cost estimation differs. Infracost parses Terraform plans and estimates monthly spend. CloudFormation has no direct equivalent—teams use AWS Cost Explorer after deployment or third-party scanners. For budget-sensitive Nepal startups, that preview step alone can justify Terraform on AWS-only projects.

Testing matters too. Use task validate or cfn-lint for CloudFormation. Use terraform validate plus tools like Terratest for Terraform. Validate JSON outputs in pipelines with our JSON formatter when debugging state or plan artefacts.

Ongoing ops—patching, backup verification, certificate renewal—still need human process regardless of IaC choice. Our support and maintenance services cover the application layer that IaC does not replace.

Key Takeaways

• Choose CloudFormation for AWS-only footprints where you want zero state file management and fastest new-service support.
• Choose Terraform when you need multi-cloud, hybrid providers, or a richer module ecosystem with explicit plan diffs.
• Protect Terraform state with remote backends, encryption, and DynamoDB locking—never commit state to Git.
• Run both tools through CI/CD with lint, plan/change-set preview, approval gates, and policy scans before production apply.
• Treat the AWS console as read-only after IaC adoption—manual edits cause drift in both tools.
• Separate infrastructure provisioning from application deployment; IaC builds the platform, Deployer or similar tools ship the code.

People Also Ask

Can you use CloudFormation and Terraform together?

Yes. A common pattern provisions base networking with CloudFormation and manages application-specific resources with Terraform—or the reverse. Avoid managing the same resource in both tools. Pick one owner per resource to prevent state conflicts and duplicate provisioning.

Is CloudFormation going away?

No. AWS continues investing in CloudFormation, including CDK—which synthesises to CloudFormation templates. CloudFormation remains the underlying engine for most AWS-native IaC approaches. Terraform coexists rather than replaces it for AWS-only teams who prefer managed stacks.

Which is easier to learn for beginners?

CloudFormation has fewer concepts—no state backends, no provider pinning. Terraform reads more naturally thanks to HCL syntax and has a larger tutorial ecosystem. Beginners on AWS-only projects often start with CloudFormation. Developers who already know HCL from other tools pick up Terraform faster.

Does Terraform cost money?

Terraform CLI is free and open source. HashiCorp charges for Terraform Cloud team features, drift detection, and policy sets. CloudFormation itself is free—you pay only for the AWS resources stacks create. Budget at least Rs 0 for the tools; budget for the EC2, RDS, and data transfer they provision.

Pick the right IaC tool and ship with confidence

The CloudFormation vs Terraform choice is not about which tool is "better" in abstract terms. It is about cloud scope, team size, and how much operational control you want over state. AWS-only teams with minimal DevOps headcount should start with CloudFormation. Everyone else—multi-cloud, hybrid DNS, SaaS integrations—should standardise on Terraform or OpenTofu and invest in remote state from day one.

Either path beats manual console clicking. Wire IaC into your Git pipeline, enforce policy checks, and keep infrastructure changes as reviewable as application code. If you want help designing a deployment stack for a Laravel, WordPress, or custom application on AWS or VPS infrastructure, contact us to discuss architecture that matches your team and budget. For zero-downtime update patterns once infra is live, read our guide on zero-downtime infrastructure updates and explore hosting options via domain registration and hosting in Nepal.