Infrastructure as Code tool selection is one of the most consequential technical decisions a DevOps or platform engineering team makes. Migrating from Terraform to CloudFormation or from CloudFormation to CDK is painful, expensive, and time-consuming. Teams that pick based on hype rather than fit spend months unwinding the decision later.
The Terraform vs AWS CDK vs CloudFormation question surfaces constantly in architecture reviews, hiring discussions, and platform strategy conversations. All three tools can provision AWS infrastructure. All three are widely adopted. The differences that matter are in developer experience, state management, multi-cloud support, abstraction level, and the long-term maintainability of your infrastructure codebase.
This guide gives you a direct, technically honest comparison. Real code samples showing the same infrastructure provisioned with each tool. A complete feature matrix. Honest assessments of where each tool wins and where it falls short. And a decision framework that cuts through the noise.
What Each Tool Actually Is
AWS CloudFormation
AWS CloudFormation is Amazon’s native Infrastructure as Code service. You define your AWS resources in JSON or YAML templates, and CloudFormation provisions and manages the resulting resource stack. It has been available since 2011 and is deeply integrated with every AWS service.
CloudFormation uses a declarative approach: you describe the desired state of your infrastructure, and CloudFormation figures out how to reach it. There is no cost for using CloudFormation itself — you pay only for the AWS resources it provisions.
- Language: JSON or YAML (declarative)
- State management: Managed entirely by AWS — no state files to maintain
- Scope: AWS only — cannot provision resources on Azure, GCP, or third-party providers
- Cost: Free — you pay for provisioned resources only
- Learning curve: Moderate — YAML verbosity is a common friction point
HashiCorp Terraform
Terraform is an open-source Infrastructure as Code tool created by HashiCorp, using a declarative configuration language called HCL (HashiCorp Configuration Language). It supports hundreds of providers — AWS, Azure, GCP, Kubernetes, Datadog, GitHub, and more — making it the standard tool for multi-cloud and polyglot infrastructure environments.
Terraform maintains a state file that tracks the current state of your infrastructure. This state file can be stored locally or remotely (typically in S3 or Terraform Cloud) and is used to plan and apply infrastructure changes incrementally.
- Language: HCL (HashiCorp Configuration Language) — declarative
- State management: External state file — requires careful management, especially in teams
- Scope: 1,000+ providers — AWS, Azure, GCP, and virtually every major cloud and SaaS platform
- Cost: Open-source is free; Terraform Cloud and HCP Terraform add paid tiers for team features
- Learning curve: Low to moderate — HCL is readable and well-documented
AWS Cloud Development Kit (CDK)
AWS CDK is an open-source software development framework that lets you define AWS infrastructure using familiar programming languages: TypeScript, Python, Java, C#, and Go. CDK code is then synthesized (compiled) into CloudFormation templates, which are deployed through the CloudFormation service.
CDK represents a fundamental shift in IaC philosophy: instead of learning a configuration language, developers write infrastructure using the same language, IDE, testing tools, and software engineering patterns they use for application code.
- Language: TypeScript, Python, Java, C#, Go (imperative constructs, generates declarative CloudFormation)
- State management: Delegated to CloudFormation — no separate state file
- Scope: AWS only — CDK provisions AWS resources through CloudFormation
- Cost: Free — you pay for provisioned AWS resources only
- Learning curve: Low for developers already proficient in supported languages; higher for ops-focused engineers
Side-by-Side Code: The Same S3 Bucket in All Three Tools
Nothing reveals the practical differences between IaC tools faster than seeing the same infrastructure defined in each. Below is a versioned S3 bucket with server-side encryption provisioned in CloudFormation, Terraform, and CDK.
CloudFormation (YAML)
| cloudformation-s3.yaml Resources: EncryptedBucket: Type: AWS::S3::Bucket Properties: BucketName: my-encrypted-bucket VersioningConfiguration: Status: Enabled BucketEncryption: ServerSideEncryptionConfiguration: – ServerSideEncryptionByDefault: SSEAlgorithm: AES256 PublicAccessBlockConfiguration: BlockPublicAcls: true BlockPublicPolicy: true IgnorePublicAcls: true RestrictPublicBuckets: true |
Terraform (HCL)
| main.tf resource “aws_s3_bucket” “encrypted_bucket” { bucket = “my-encrypted-bucket” }
resource “aws_s3_bucket_versioning” “versioning” { bucket = aws_s3_bucket.encrypted_bucket.id versioning_configuration { status = “Enabled” } }
resource “aws_s3_bucket_server_side_encryption_configuration” “sse” { bucket = aws_s3_bucket.encrypted_bucket.id rule { apply_server_side_encryption_by_default { sse_algorithm = “AES256” } } }
resource “aws_s3_bucket_public_access_block” “block” { bucket = aws_s3_bucket.encrypted_bucket.id block_public_acls = true block_public_policy = true ignore_public_acls = true restrict_public_buckets = true } |
AWS CDK (TypeScript)
| infrastructure.ts import * as s3 from ‘aws-cdk-lib/aws-s3’; import { Stack, StackProps } from ‘aws-cdk-lib’; import { Construct } from ‘constructs’;
export class StorageStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props);
new s3.Bucket(this, ‘EncryptedBucket’, { bucketName: ‘my-encrypted-bucket’, versioned: true, encryption: s3.BucketEncryption.S3_MANAGED, blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL, }); } } |
Key observation: CDK achieves the same result in the fewest lines, with the strongest type safety. Terraform is explicit and readable. CloudFormation is the most verbose. For larger infrastructure codebases, these differences compound significantly.
Terraform vs AWS CDK vs CloudFormation: Full Feature Matrix
| Dimension | AWS CloudFormation | HashiCorp Terraform | AWS CDK |
| Language | JSON / YAML (declarative) | HCL (declarative) | TypeScript, Python, Java, C#, Go |
| State Management | Managed by AWS — no state file | External state file (S3, TFC) | Delegated to CloudFormation |
| Cloud Scope | AWS only | 1,000+ providers (multi-cloud) | AWS only |
| Abstraction Level | Low — resource-level definitions | Low-medium — resource + modules | High — constructs + patterns |
| Cost | Free (pay for resources) | Open-source free / paid tiers | Free (pay for resources) |
| AWS Integration | Native — deepest AWS support | Strong via AWS provider | Native via CloudFormation |
| New AWS Services | Day 1 support | Provider update required | Day 1 via CloudFormation escape hatch |
| Testing | Limited (cfn-lint, cfn-nag) | terratest, native tests | Jest, pytest — full unit testing |
| Reusability | Nested stacks, modules | Modules, registry | Constructs, construct libraries |
| Drift Detection | Built-in | terraform plan detects drift | Built-in via CloudFormation |
| IDE Support | YAML completion (limited) | Strong HCL plugins | Full IDE support — autocomplete, types |
| Rollback on Failure | Automatic (configurable) | Manual intervention required | Automatic via CloudFormation |
| Community | Large AWS community | Largest IaC community | Growing rapidly |
| Vendor Lock-in | Full AWS lock-in | Portable across providers | Full AWS lock-in |
| Best For | Simple AWS deployments, compliance | Multi-cloud, enterprise platform | Developer-led AWS teams |
The CloudFormation Story: When Native Is Enough
CloudFormation is often underestimated. As the native AWS IaC tool, it receives Day 1 support for every new AWS service, has zero additional cost, integrates directly with IAM, Service Control Policies, AWS Config, and AWS Organizations, and requires no state file management.
Where CloudFormation Wins
- Day 1 AWS service support: New AWS services are immediately available in CloudFormation templates — often before third-party tools add support
- No state file complexity: CloudFormation manages state internally. No risk of state file corruption, locking issues, or S3 permissions problems that affect Terraform teams
- Automatic rollback: If a stack update fails, CloudFormation automatically rolls back to the previous working state — a significant operational safety net
- Native AWS integrations: CloudFormation integrates directly with Service Catalog, AWS Control Tower, StackSets for multi-account deployments, and AWS Organizations
- Compliance and audit: CloudFormation change sets provide a reviewed, auditable record of infrastructure changes before deployment — valuable in regulated environments
- Zero cost: Unlike Terraform Cloud, CloudFormation has no licensing or platform cost beyond the AWS resources it provisions
Where CloudFormation Loses
- Verbosity at scale: Large CloudFormation templates become difficult to maintain. A production EKS cluster with VPC, IAM, and monitoring can run to thousands of lines of YAML
- AWS-only scope: If any part of your infrastructure lives outside AWS GitHub Actions, Datadog, Cloudflare, PagerDuty — CloudFormation cannot manage it
- Limited abstraction: CloudFormation operates at the resource level. There are no built-in abstractions for common patterns like ‘secure S3 bucket’ or ‘EKS cluster with best practice security settings’
- Developer experience: Writing YAML with no type safety, limited IDE support, and no unit testing framework is a productivity disadvantage for developer-led teams
| Pro Tip CloudFormation StackSets are underutilized. If you are managing infrastructure across multiple AWS accounts — whether for multi-region deployments, organizational unit separation, or security boundaries — StackSets allow you to deploy the same template to hundreds of accounts and regions with a single operation. This is a genuine competitive advantage over Terraform for AWS Organizations users. |
The Terraform Story: The Multi-Cloud Standard
Terraform’s dominance in enterprise IaC comes from one primary advantage: it works everywhere. The same tooling, workflow, and team expertise applies whether you are provisioning AWS EC2, Azure Kubernetes Service, GCP Cloud Run, Cloudflare DNS records, or GitHub repository settings.
Where Terraform Wins
- Multi-cloud and multi-provider: 1,000+ providers mean Terraform can manage virtually every aspect of your modern infrastructure stack from a single tool
- HCL readability: HashiCorp Configuration Language is purpose-built for infrastructure definition — readable, explicit, and easier to review than YAML or general-purpose programming language code
- Module ecosystem: The Terraform Registry contains thousands of community and official modules. An AWS VPC with best-practice defaults, an EKS cluster, an RDS instance — modules for these exist and are maintained by AWS and the community
- Explicit dependency management: Terraform’s dependency graph makes resource ordering explicit and predictable — useful for debugging complex infrastructure dependencies
- Mature state management: Remote state in S3 with DynamoDB locking is a well-understood, widely documented pattern that handles team concurrency safely
- Plan before apply: terraform plan generates a human-readable preview of exactly what will change before any resource is modified — arguably the most important operational safety feature in IaC
Where Terraform Loses
- State file risk: The Terraform state file is the source of truth for your infrastructure. State corruption, drift between state and reality, or incorrect state imports can cause cascading failures. This risk requires careful operational discipline
- AWS service lag: New AWS services require a provider update before Terraform can manage them. For teams on the cutting edge of AWS service adoption, this lag (typically days to weeks) can be a friction point
- No automatic rollback: Unlike CloudFormation, Terraform does not automatically roll back failed applies. Partial failures require manual remediation — a significant operational risk in complex deployments
- Licensing changes: HashiCorp’s 2023 move to the Business Source License (BSL) introduced uncertainty about Terraform’s open-source future. OpenTofu (the community fork) emerged as an alternative, but adds fragmentation to the ecosystem
The AWS CDK Story: Infrastructure as Real Code
AWS CDK represents a different philosophy from CloudFormation and Terraform. Rather than learning a domain-specific language, developers define infrastructure using the same programming languages, IDEs, testing tools, and software engineering patterns they already use for application code.
CDK synthesizes to CloudFormation templates at deploy time — which means CDK inherits CloudFormation’s operational model: automatic rollback, AWS-native state management, and Day 1 service support.
Where CDK Wins
- Developer experience: Full IDE support — autocompletion, type checking, inline documentation, and refactoring tools work exactly as they do for application code. Mistakes caught at compile time, not deploy time
- Abstraction through constructs: CDK’s construct system provides three levels of abstraction — L1 (raw CloudFormation), L2 (opinionated defaults with best practices built in), and L3 (complete patterns). An L2 S3 Bucket construct enforces encryption and public access blocking by default
- Unit testing: CDK stacks can be tested with Jest or pytest before any deployment. Testing that a Lambda function has the right IAM permissions, or that an RDS instance has deletion protection enabled, is straightforward
- Reusable construct libraries: Teams can build and publish their own construct libraries — internal platforms that encapsulate organizational standards for security, networking, and compliance into reusable components
- No state file: CDK deploys through CloudFormation, which manages state. No S3 buckets for state files, no DynamoDB tables for locking, no state corruption risk
- Imperative logic: Looping to create 50 S3 buckets, conditionally enabling features based on environment variables, or building complex IAM policies dynamically — all straightforward in a real programming language, painful in YAML or HCL
Where CDK Loses
- AWS only: CDK generates CloudFormation templates. It cannot manage Cloudflare, Datadog, GitHub, or any non-AWS resource
- Steep curve for ops engineers: CDK requires comfort with TypeScript, Python, or another supported language. Platform and infrastructure engineers who are not primarily developers may find the learning curve steeper than HCL or YAML
- Synthesized template opacity: The CloudFormation templates CDK generates can be long and difficult to read or debug. When something goes wrong at the CloudFormation level, tracing the issue back to CDK code requires understanding both layers
- Faster-moving API surface: CDK releases frequently and occasionally introduces breaking changes between major versions. Teams need active dependency management discipline
Conclusion: The Right IaC Tool for Your Infrastructure
The Terraform vs AWS CDK vs CloudFormation decision is not about which tool is objectively best — it is about which tool best matches your architecture, team skills, and long-term infrastructure strategy.
Key takeaways:
- CloudFormation is the right choice for AWS-native teams that value simplicity, zero tooling cost, automatic rollback, and native AWS integrations over abstraction and developer experience
- Terraform is the right choice for multi-cloud environments, hybrid infrastructure, or organizations that manage non-AWS resources alongside cloud resources and want a single tool across the full stack
- AWS CDK is the right choice for developer-led teams that are AWS-native, want real programming language tooling, and value abstraction, unit testing, and reusable construct libraries over simplicity
- Hybrid patterns combining Terraform for foundational infrastructure and CDK for application resources represent the mature enterprise approach — leveraging each tool’s strengths
- Migration cost is real — choose your primary IaC tool based on your 3-5 year infrastructure vision, not your current team preferences, because switching tools is expensive
Whichever tool you choose from this Terraform vs AWS CDK vs CloudFormation comparison, the most important next step is consistency: establish a single tool standard, build your reusable module or construct library, and enforce infrastructure review processes from day one.
Infrastructure drift, undocumented resources, and unreviewed changes are the real risks in IaC — and all three tools solve those risks when used with discipline.
