Terraform vs AWS CDK vs CloudFormation: The 2026 Comparison Guide

Anastasiia Kuten Marketing & Partnerships Department Manager

May 8, 2026

AWS partner dedicated to startups

• 2000+ Clients
• 5+ Years of Experience
• $10M+ saved on AWS

You are about to make a decision that will shape your infrastructure code for the next 3 to 5 years. So let’s compare Terraform vs AWS CDK vs CloudFormation. Migration between these tools is painful and expensive, so picking the right one matters more than picking the trendy one.

This guide cuts through the marketing and gives you the honest, up-to-date 2026 comparison of the three most-used Infrastructure as Code (IaC) tools on AWS: Terraform, AWS CDK, and AWS CloudFormation. Real benchmarks, side-by-side code, and a clear decision framework so you can pick the right tool for your situation, not just the popular one.

The Short Answer (For Busy Readers)

If none of those describe you exactly, keep reading. The full picture is more nuanced.

What Each Tool Actually Is

AWS CloudFormation

AWS CloudFormation is AWS’s native Infrastructure as Code service. You write YAML or JSON templates describing AWS resources, and CloudFormation provisions them. It is the foundation that every other AWS-native IaC tool builds on, including CDK and SAM.

CloudFormation is free to use. You only pay for the resources it creates.

HashiCorp Terraform

Terraform is an open-source IaC tool that manages infrastructure across more than 3,000 providers, including AWS, Azure, Google Cloud, Kubernetes, GitHub, Datadog, and most other platforms you can name. You write code in HashiCorp Configuration Language (HCL), and Terraform calls the underlying provider APIs directly to provision resources.

Terraform was relicensed under the Business Source License (BSL) in August 2023. The community fork, OpenTofu, maintains the original Mozilla Public License.

AWS Cloud Development Kit (CDK)

AWS CDK is an open-source framework that lets you define AWS infrastructure using real programming languages: TypeScript, Python, Java, C#, or Go. Your CDK code is synthesized into CloudFormation templates, which CloudFormation then deploys.

The key insight: CDK is a layer on top of CloudFormation, not a replacement for it. You get all the state management benefits (and constraints) of CloudFormation, plus the expressiveness of a real programming language.

Side-by-Side Code: Same EKS Cluster, Three Tools

Nothing illustrates the differences better than seeing the same infrastructure defined in all three tools. Here is a basic EKS cluster in each.

CloudFormation (YAML)

Resources:
  EKSCluster:
    Type: AWS::EKS::Cluster
    Properties:
      Name: production
      RoleArn: !GetAtt EKSRole.Arn
      ResourcesVpcConfig:
        SubnetIds:
          - !Ref PrivateSubnet1
          - !Ref PrivateSubnet2
      Version: "1.31"

  EKSRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service: eks.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonEKSClusterPolicy

Terraform (HCL)

resource "aws_eks_cluster" "main" {
  name     = "production"
  role_arn = aws_iam_role.eks.arn
  version  = "1.31"

  vpc_config {
    subnet_ids = aws_subnet.private[*].id
  }
}

resource "aws_iam_role" "eks" {
  name = "eks-cluster-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = { Service = "eks.amazonaws.com" }
      Action = "sts:AssumeRole"
    }]
  })

  managed_policy_arns = [
    "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
  ]
}

AWS CDK (TypeScript)

import * as eks from 'aws-cdk-lib/aws-eks';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

const cluster = new eks.Cluster(this, 'ProductionCluster', {
  version: eks.KubernetesVersion.V1_31,
  vpc: vpc,
  defaultCapacity: 0,
  clusterName: 'production',
});

That is not a fair comparison in one sense: the CDK example does a lot more behind the scenes. The L2 construct creates the cluster, the IAM roles, the security groups, the cluster logging, and applies AWS best practices automatically. With CloudFormation or Terraform, you would write all of that explicitly.

This is the trade-off: CDK gives you abstraction, Terraform gives you explicitness, CloudFormation gives you raw AWS control.

Full Feature Comparison

The CloudFormation Story

Where CloudFormation Wins

• Day-1 AWS service support. Every new AWS service ships with CloudFormation support immediately. With Terraform, you wait days or weeks for the AWS provider to update.
• State managed for free. No S3 buckets, no DynamoDB locking tables, no Terraform Cloud subscription. AWS handles the state for you.
• Automatic rollback. If a deployment fails partway through, CloudFormation rolls back to the previous working state automatically. With Terraform, you are stuck cleaning up half-deployed infrastructure manually.
• Stack policies and drift detection built in.
• No vendor lock-in concerns. AWS is not going to change the license on CloudFormation.
• Free. No tooling cost, no subscription, no surprises.

Where CloudFormation Loses

• YAML/JSON is not a programming language. Loops, conditionals, and abstractions are clunky. Anything beyond simple infrastructure becomes verbose quickly.
• 2,000-line YAML files are not maintainable. Once your infrastructure grows, raw CloudFormation becomes a nightmare to navigate and refactor.
• Limited reusability. Modules and nested stacks exist but are not as ergonomic as Terraform modules or CDK constructs.
• AWS-only. If you ever need to manage anything outside AWS, you need a second tool.
• Slower deployments. CloudFormation has service overhead that adds 1 to 2 minutes per deployment compared to Terraform.

When to Pick CloudFormation

CloudFormation makes sense if you are 100% AWS-native, your team prefers declarative YAML, and you want zero tooling overhead. It is also the right pick if you have strict compliance requirements that need every change to go through AWS-managed services. Many enterprises, regulated industries, and AWS-first shops still default to CloudFormation for these reasons.

For serverless workloads specifically, AWS SAM (a CloudFormation superset focused on Lambda and event-driven apps) is often the better starting point.

The Terraform Story

Where Terraform Wins

• Multi-cloud is first-class. A single Terraform workspace can provision resources across AWS, Azure, GCP, Kubernetes, and 3,000+ other providers. CloudFormation and CDK cannot do this.
• terraform plan is genuinely outstanding. Before applying any change, you get a precise, human-readable diff of what will be created, modified, or destroyed. For team trust and safety, this is hard to beat.
• Mature module ecosystem. The Terraform Registry has thousands of community modules for common patterns (VPCs, EKS clusters, security baselines).
• Direct API calls. Terraform calls AWS APIs directly without an intermediary like CloudFormation. This makes deployments roughly 2x faster.
• terraform import is mature. Bringing existing AWS resources under Terraform management is a well-documented, supported workflow. CloudFormation and CDK have improved here but are still less mature.
• Job market demand. Roughly 65% of cloud job postings list Terraform as a required or preferred skill.
• Cloud-agnostic skills. Learn Terraform once, use it on any cloud.

Where Terraform Loses

• HCL is not a real programming language. for_each, count, and dynamic blocks cover most cases, but complex conditional logic across multiple config objects gets messy. You will hit limits.
• State file is a liability. The state file must be stored securely (it can contain plaintext secrets), versioned, and locked during concurrent runs. You need a remote backend like S3 with DynamoDB locking. This is solved, but it is operational overhead that CloudFormation users never face.
• AWS provider lag. New AWS features can take days to weeks to land in the hashicorp/aws provider. Day-1 launches are not always supported.
• Manual rollback. When a deployment fails partway through, you have to clean it up yourself. There is no automatic rollback.
• Licensing concerns. The 2023 license change to BSL created uncertainty for some enterprises. OpenTofu mitigates this but adds another tool to evaluate.
• Pricing for Terraform Cloud at scale. Free tier is generous, but enterprise pricing can be steep.

When to Pick Terraform

Terraform is the right call when:

1. You have multi-cloud requirements (real ones, not theoretical)
2. Your team is operations-heavy and prefers declarative syntax
3. Your organization already has Terraform expertise or modules
4. You want maximum portability and freedom from cloud lock-in
5. You manage infrastructure across many SaaS providers (GitHub, Datadog, Cloudflare, etc.)

The AWS CDK Story

Where AWS CDK Wins

• Real programming languages. Loops, conditionals, classes, inheritance, package managers, IDE autocomplete, type checking. If you are a software engineer, this feels like home.
• Powerful abstractions (L1, L2, L3 constructs). An ApplicationLoadBalancedFargateService construct creates ECS Fargate, an Application Load Balancer, target groups, health checks, IAM roles, and CloudWatch logs in one line of code with sensible defaults.
• Day-1 AWS support via L1 constructs. Every CloudFormation resource is available in CDK from launch day. You never wait for a provider update.
• State managed by CloudFormation. No state file headaches.
• Automatic rollback inherited from CloudFormation.
• Native testing frameworks. Use Jest for TypeScript, pytest for Python, JUnit for Java. Real unit tests with mocks, snapshots, and assertions.
• Active 2025 to 2026 feature development. CDK Toolkit Library, CDK Refactor, CDK Mixins (March 2026), and improved migration tools have widened the gap against Terraform for AWS-native teams.

Where AWS CDK Loses

• AWS-only. CDK does not work for multi-cloud. CDKTF (CDK for Terraform) was deprecated by HashiCorp in 2025, eliminating the “best of both worlds” escape hatch.
• Slower than Terraform. Because CDK deploys via CloudFormation, you get the same 2 to 3x speed penalty CloudFormation has.
• Steeper learning curve for ops-only teams. If your team does not write code regularly, CDK feels foreign.
• The abstraction can hide complexity. When something goes wrong, you may need to dig through synthesized CloudFormation to figure out what happened.
• Bundle size. The CDK Construct Library is large, and CDK projects can have large dependency trees.
• Less mature import workflow. Bringing existing AWS resources under CDK management is improving but still less smooth than Terraform.

When to Pick AWS CDK

CDK is the right call when:

1. Your team is full of software developers, not just ops engineers
2. You are AWS-only and committed to staying that way
3. You want the highest abstraction with the least boilerplate
4. You want infrastructure code that lives next to application code in the same language
5. You value testing infrastructure with real unit tests, not just lint checks

Performance Benchmarks

Real-world deployment time measurements for a typical 10 to 20 resource stack (VPC + EKS cluster + RDS + S3 + IAM):

Terraform is roughly 2x faster than CDK and CloudFormation because it calls AWS APIs directly. CDK’s cdk watch command partially closes this gap during development by hot-swapping Lambda and ECS updates without going through CloudFormation.

Cost Comparison

All three tools are free to use as open-source software. The cost comes from operational overhead and supporting services.

Migration Between Tools

Migrations are possible but expensive. Plan once, choose carefully.

The CDKTF Question (And Why It No Longer Matters)

For years, the answer to “can I get the best of both worlds?” was CDK for Terraform (CDKTF). It let you write CDK-style code that synthesized to Terraform configurations instead of CloudFormation. In theory, you got CDK’s expressiveness with Terraform’s multi-cloud support.

HashiCorp deprecated CDKTF in 2025. It is no longer actively maintained. If you were considering CDKTF as your escape hatch from picking between CDK and Terraform, that escape hatch is now closed.

This deprecation actually clarifies the decision: the choice between CDK and Terraform is now a real architectural commitment, not something you can hedge.

Decision Framework: Pick Your Tool in 60 Seconds

Walk through these questions in order. Stop at the first one where you have a clear answer.

1. Do you need multi-cloud support today, or in the next 18 months?
   • Yes → Terraform. Stop here.
   • No → continue.
2. Does your team already have significant Terraform expertise or invested modules?
   • Yes → Terraform. The cost of switching outweighs benefits.
   • No → continue.
3. Is your team primarily software developers, or primarily ops/SRE engineers?
   • Software developers → AWS CDK. Programming languages will make them faster.
   • Ops/SRE → continue.
4. Do you need to manage infrastructure outside AWS (GitHub, Datadog, Cloudflare, etc.)?
   • Yes → Terraform.
   • No → continue.
5. Do you have strict enterprise compliance requirements that mandate AWS-native tooling?
   • Yes → CloudFormation (or CDK with strict approval gates).
   • No → continue.
6. Default for everyone else: AWS CDK. Best abstractions, fastest development, full AWS integration.

Common Patterns in Real Teams

Pattern 1: CDK for Apps, Terraform for Foundation

Some teams use Terraform for the long-lived foundational infrastructure (VPCs, IAM baselines, multi-account setup, security tools) and CDK for application-specific stacks. This works because foundational infra rarely changes and benefits from Terraform’s explicitness, while application stacks change frequently and benefit from CDK’s expressiveness.

Trade-off: two tools means two skill sets and two state management approaches. Only worth it for large teams with clear boundaries.

Pattern 2: CloudFormation for Infrastructure, SAM for Serverless

For pure AWS shops with serverless-heavy workloads, CloudFormation handles the long-lived infrastructure and AWS SAM handles Lambda functions, API Gateway, EventBridge, and Step Functions. SAM is a CloudFormation superset designed specifically for serverless ergonomics.

Pattern 3: Pure CDK

The simplest approach for AWS-only teams. One tool, one language, one workflow. As CDK has matured (especially with 2025 to 2026 features like Mixins and Refactor), this has become the most common choice for new AWS-native projects.

Pattern 4: Pure Terraform

Common for established companies with multi-cloud presence or strong ops culture. One tool covers everything from AWS infrastructure to GitHub permissions to Datadog dashboards. The operational simplicity of one tool often beats the abstraction power of CDK for these teams.

Best Practices Regardless of Tool

• Version control everything. All IaC code lives in Git. Code review every change.
• Separate environments at the stack level. Dev, staging, and prod should be separate stacks/workspaces, not shared with conditional logic.
• Use remote state (Terraform) or stack policies (CloudFormation/CDK). Never store state locally in production.
• Tag everything. Implement consistent tagging at the IaC layer for cost allocation, security, and inventory.
• Run plan/diff in CI before merging. Every PR should show what will change before it gets merged.
• Encrypt secrets properly. Use AWS Secrets Manager or Parameter Store. Never hardcode credentials in IaC.
• Test before applying. Lint your code, run unit tests where supported, and use ephemeral test environments for integration testing.
• Lock provider versions. Pin Terraform providers, CDK Construct Library, and CloudFormation transforms to avoid surprise upgrades.
• Document your IaC structure. A README at the top of every IaC repo explaining the layout, deployment steps, and tool versions.

Frequently Asked Questions

Which is the most popular IaC tool for AWS in 2026?
Terraform has the largest overall market share by job postings (around 65%), but AWS CDK is the fastest-growing tool for AWS-native teams. CloudFormation remains widely used in enterprises and as the foundation under CDK.

Should I learn Terraform or CDK first?
Learn Terraform first. It is in more job postings, works across clouds, and the concepts transfer to CDK and Pulumi. Once you understand declarative IaC and state management, learning CDK is much easier.

Is CDK production-ready?
Yes. CDK has been production-ready since 2020. Major companies including Liberty Mutual, GoDaddy, and Bain Capital use CDK at scale. The 2025 to 2026 feature additions (Toolkit Library, Refactor, Mixins) have made it more enterprise-friendly than ever.

Is OpenTofu a real Terraform alternative?
Yes. OpenTofu is a fork of Terraform that maintains the original Mozilla Public License. It is fully Terraform-compatible, governed by the Linux Foundation, and is a viable choice if open-source licensing is a hard requirement for your organization.

Can I use multiple IaC tools in the same project?
Yes, with care. The most common pattern is Terraform for foundational infrastructure (VPCs, IAM, accounts) and CDK or SAM for application stacks. The risk is operational complexity, two state systems, and team confusion about which tool owns what.

What about Pulumi?
Pulumi is a fourth option that uses real programming languages like CDK but supports multi-cloud like Terraform. It is less popular than the big three but worth considering if you specifically need both CDK-style ergonomics and multi-cloud support.

Does CDK lock me into AWS forever?
Yes, in practice. CDK only generates CloudFormation, which only deploys to AWS. If you might leave AWS or go multi-cloud, Terraform is the safer architectural choice.

Why is Terraform faster than CloudFormation?
Terraform calls AWS APIs directly. CloudFormation has a service layer between your template and the APIs that adds overhead. For large stacks, the difference can be several minutes per deployment.

Is CloudFormation going away?
No. CDK synthesizes to CloudFormation, so AWS continues to invest heavily in it. CloudFormation will be around as long as AWS exists.

Should I use AWS SAM instead of CDK for serverless?
Both work well. SAM is simpler if your project is purely serverless (Lambda, API Gateway, EventBridge, Step Functions). CDK is better if your project mixes serverless with other AWS services or you want to share code between application logic and infrastructure.

Summary: Which One Should You Pick?

If you remember nothing else, remember this:

• AWS CDK wins for AWS-native teams with software engineering culture, programming language preference, and a long-term commitment to AWS.
• Terraform wins for multi-cloud and platform teams, ops-heavy organizations, and anyone who values declarative syntax and broad ecosystem support.
• CloudFormation wins for strict AWS-native enterprises, compliance-heavy environments, and teams that want zero tooling overhead with AWS-managed state and rollback.

The IaC decision is a 3 to 5 year commitment. Pick based on your team, your strategy, and your real requirements, not on what is trendy. All three tools work and work well. The wrong tool for your team will hurt more than the right tool slightly underperforming.

Whatever you choose, commit to it. Switching IaC tools mid-project costs months of work. Switching twice costs careers.