CDK vs Terraform vs CloudFormation: Choosing the Right IaC Language and Tool#
Infrastructure as Code has fundamentally changed how we deploy and manage cloud resources. Rather than clicking through a console or writing brittle shell scripts, we now describe our infrastructure in declarative or imperative code that can be version-controlled, tested, and reliably reproduced across environments. But choosing which tool to use—AWS CDK, Terraform, or CloudFormation—is rarely straightforward. Each approach has genuine strengths and meaningful trade-offs that become apparent only when you understand what each tool is actually doing under the hood and what problems it solves.
This article cuts through the hype and comparison tables to give you the context you need to make a confident decision. We’ll explore how each tool works, what kinds of teams and projects they’re best suited for, and the architectural realities that shape their differences.
Understanding the Three Approaches#
Before we compare, let’s establish what we’re actually comparing. These three tools sit at different points in the infrastructure-as-code landscape, and they make fundamentally different choices about how much abstraction and flexibility to offer.
CloudFormation is AWS’s native infrastructure-as-code service. You write templates in YAML or JSON that describe your desired AWS resources—EC2 instances, RDS databases, Lambda functions, S3 buckets, and hundreds of other AWS service resources. You submit this template to the CloudFormation service, which interprets it and creates or updates your actual infrastructure. CloudFormation is declarative: you describe the end state you want, and CloudFormation figures out what changes are needed to get there.
Terraform is an open-source tool created and maintained by HashiCorp that lets you write infrastructure code using a language called HCL (HashiCorp Configuration Language). The critical difference: Terraform works with dozens of cloud providers—AWS, Google Cloud, Azure, DigitalOcean, and many others—treating them through a unified abstraction layer called providers. You write Terraform configuration once, and the same patterns work across multiple clouds.
AWS CDK (Cloud Development Kit) is AWS’s programmatic approach to infrastructure as code. Instead of writing YAML or a domain-specific language, you write actual programming code in TypeScript, Python, Java, Go, or C# to define your infrastructure. The CDK compiles this code down to a CloudFormation template, which is then deployed using CloudFormation. This is the crucial insight: CDK is a higher-level abstraction on top of CloudFormation, not an alternative to it.
The Declarative vs. Imperative Divide#
This is where the philosophical differences start to matter. CloudFormation and Terraform are declarative: you declare what you want, and the tool handles the how. CDK is imperative: you write code that constructs your infrastructure, step by step, using familiar programming language features like loops, conditionals, and functions.
Consider a scenario where you need to create ten identical subnets across availability zones. In CloudFormation or Terraform, you’d likely use a loop construct (or similar feature) to generate multiple resources from a single block. In CDK, you’d write a for loop in your programming language of choice, adding a subnet to your VPC with each iteration. It sounds like a small difference, but it fundamentally changes how you think about and structure your infrastructure code.
This imperative approach gives CDK an enormous advantage: you have the full power of a real programming language at your fingertips. You can write functions, create reusable constructs, implement inheritance, add unit tests, and organize code exactly like you would any other software project. If you’re a developer who spends most of your time writing application code, CDK feels like home. You’re not learning a new domain-specific language; you’re using skills you already have.
CloudFormation and Terraform require you to learn their syntax and semantics, but they offer a different kind of clarity: what you see is what you get. A CloudFormation template is explicit about every resource being created. There’s no hidden logic or loops to understand; it’s all there in the file. Some teams prefer this explicitness, especially in highly regulated environments where every resource must be auditable and traceable.
Learning Curve and Accessibility#
If you’re starting from scratch, Terraform has perhaps the gentlest learning curve. HCL is designed to be readable, the syntax is relatively intuitive, and the Terraform community has built extensive documentation and examples. You can write useful Terraform configuration with just a few hours of study.
CloudFormation is more challenging to learn. YAML syntax is finicky—indentation matters, quotes matter, and error messages are sometimes cryptic. The documentation, while comprehensive, is often dense and technical. Learning CloudFormation means learning both the syntax and developing an intuition for how CloudFormation stacks, resources, and change sets work. However, once you’ve learned it, the knowledge translates directly to understanding how AWS services work together.
CDK has a medium learning curve that depends heavily on your programming background. If you’re comfortable with Python or TypeScript and understand object-oriented concepts, CDK will feel straightforward. The CDK documentation is well-written, and the code reads like the application code you already know. However, you still need to understand what CDK is doing behind the scenes—that it’s generating CloudFormation—and you need to understand the underlying AWS concepts. You can’t abstract away the need to know what an IAM role is or how a VPC works; CDK just lets you express those concepts programmatically.
Abstraction Levels and the Construct Philosophy#
One of CDK’s defining features is the idea of constructs—reusable, higher-level components that bundle multiple AWS resources together. The CDK library includes constructs at different levels of abstraction.
L1 constructs (low-level) map one-to-one with CloudFormation resources. CfnBucket is a low-level construct representing a single S3 bucket with all its configuration options. L2 constructs (mid-level) bundle related resources together with sensible defaults and patterns. The Bucket construct, for example, manages not just the S3 bucket itself but also its configuration for common use cases. L3 constructs (high-level, often called patterns) go further, encapsulating entire architectural patterns. A construct might create a VPC, subnets, NAT gateways, and route tables all in one line of code, with sane defaults appropriate for most applications.
This layering is powerful. You can start with high-level patterns for quick wins, then drill down to L2 constructs when you need more control, then to L1 when you need complete customization. You never get trapped in someone else’s abstraction.
Terraform offers a similar concept through modules, which are reusable collections of resources. A well-designed Terraform module can encapsulate complexity and provide a clean interface, much like a CDK construct. The Terraform Registry contains thousands of modules. However, modules are less standardized than CDK constructs. Quality varies widely, and there’s less of an official ecosystem backing them up.
CloudFormation doesn’t have built-in abstraction mechanisms. You can organize templates into nested stacks, but this requires more manual orchestration. Some teams use tools like AWS SAM (Serverless Application Model) or Troposphere (a Python library that generates CloudFormation) to add abstraction layers on top of CloudFormation, but these are unofficial approaches.
Vendor Lock-in and Multi-Cloud Considerations#
This is where Terraform’s architecture reveals its greatest strategic advantage. Because Terraform abstracts away the differences between cloud providers, writing your infrastructure code with Terraform creates genuine optionality. You could run your infrastructure on AWS today, switch significant portions to Google Cloud tomorrow, or adopt a multi-cloud strategy without rewriting all your IaC code. The skill investment in learning Terraform transfers directly to other clouds.
CloudFormation and CDK are AWS-specific. There’s no portability; you’re committed to AWS, full stop. For some organizations, this is a feature, not a bug. If you’ve chosen AWS as your long-term cloud provider and have no intention of multi-cloud adoption, there’s no reason to abstract away AWS-specific details. You might as well use tools built specifically for AWS that can take advantage of all AWS capabilities as soon as they’re released.
But “vendor lock-in” is more nuanced than it sounds. Even with Terraform, you’re building on AWS infrastructure. Your applications are written for AWS services. Your engineers know AWS APIs. Switching clouds isn’t a straightforward translation of your Terraform code; it requires rethinking application architecture, retraining teams, and evaluating whether similar services exist in other clouds. In practice, most organizations that choose Terraform do so for flexibility, not because they actually plan to migrate clouds. The optionality matters more psychologically than practically.
CDK’s situation is slightly different. You’re locked into AWS, but that lock-in is very tight. CDK has native support for every AWS service—often with more idiomatic constructs than CloudFormation itself. If AWS releases a new service, CDK usually has constructs for it quickly. You’re not just locked into AWS; you’re getting the full value of that lock-in.
Service Coverage and Completeness#
CloudFormation supports essentially all AWS services. If it exists in AWS, you can likely provision it with CloudFormation. AWS maintains resource definitions for everything from common services like EC2 and S3 to specialized offerings like AppConfig and ControlTower.
CDK builds on top of CloudFormation, so theoretically every CloudFormation resource is available through L1 constructs. In practice, CDK’s true power comes from L2 and L3 constructs, which don’t exist for every service. Popular services like EC2, RDS, Lambda, and DynamoDB have rich construct libraries. Newer or more specialized services might only have L1 constructs, which defeats some of the purpose of using CDK.
Terraform’s coverage of AWS services is strong but slightly behind CloudFormation. HashiCorp focuses on popular services first, and more obscure or newly released services can lag. For mainstream applications, this is rarely a practical limitation, but it’s worth checking before committing to Terraform for a project that relies heavily on niche services.
State Management and Drift Detection#
Here’s a subtle but critical difference: how these tools track what infrastructure actually exists.
CloudFormation keeps state on the AWS side. When you create a stack, CloudFormation maintains a record of what it created. When you update the stack, CloudFormation knows what already exists and what needs to change. CloudFormation also provides drift detection: you can ask CloudFormation to inspect your actual resources and report any differences from what the template declares. If someone manually changes something in the console, drift detection will catch it.
Terraform maintains state in a state file, typically stored locally or in remote storage like S3. This state file is Terraform’s source of truth about what resources exist. If you lose the state file, Terraform doesn’t know what it created, and you’ll have serious problems. Terraform also provides drift detection, but it requires running terraform plan against actual infrastructure. Terraform’s state management is more flexible but more complex—you have to think about where the state lives, how to back it up, and how to manage concurrent access when teams work together.
CDK generates CloudFormation templates, so it inherits CloudFormation’s state management. CDK itself doesn’t maintain state; the CloudFormation stack does. This simplifies things considerably. You can regenerate your CDK infrastructure from code at any time, redeploy it, and CloudFormation will handle the reconciliation.
Team Dynamics and Skill Fit#
The right tool for your infrastructure depends significantly on your team’s existing skills and how your organization is structured.
If your team is primarily application developers with deep expertise in a specific language—Python shops or TypeScript shops, for example—CDK is a natural fit. You can leverage existing skills and tools. Your infrastructure code can live in the same repository as your application code and follow the same testing and deployment patterns. Infrastructure becomes just another part of the codebase.
If your team includes dedicated DevOps or infrastructure engineers, CloudFormation might be preferable. These engineers often have deep AWS knowledge and appreciate the explicit, unambiguous nature of CloudFormation templates. The friction of learning yet another tool might not be worth it when they’re already fluent in AWS.
If your organization is multi-cloud or has teams spread across different cloud providers, Terraform becomes essential. The consistency across clouds, the existing training investment, and the ability to share knowledge across teams all pull toward Terraform.
Size and structure matter too. Startups and smaller teams often gravitate toward CDK because the language-as-infrastructure model reduces cognitive overhead—you’re not learning multiple tools, just using the language you already know. Large enterprises sometimes prefer CloudFormation or Terraform because they provide a more standardized, auditable, and consistent approach across diverse teams and applications.
How CDK Actually Works: The CloudFormation Connection#
Understanding CDK’s relationship to CloudFormation is crucial for making informed decisions. CDK is not a competitor to CloudFormation; it’s an abstraction layer on top of it.
When you write CDK code, you’re building an object model that represents your infrastructure. You instantiate constructs, set properties, establish relationships between resources. Then you run cdk synth (synthesize), which converts this object model into a CloudFormation template in JSON format. This template is exactly what you’d write by hand in CloudFormation, just generated from your CDK code. Then cdk deploy submits this template to CloudFormation, which does the actual work of creating resources.
This architecture has important implications. First, you can always see what CloudFormation template CDK is generating. If something looks wrong, you can examine the template directly. This transparency is valuable for debugging and understanding what’s really happening.
Second, your CDK code can be version-controlled and peer-reviewed just like application code. You can run unit tests against your infrastructure. You can extract common patterns into reusable constructs. You can use your programming language’s full feature set to eliminate repetition and build composable abstractions.
Third, you’re not creating a parallel infrastructure management system. You’re still using CloudFormation under the hood; you’re just using a better interface to generate CloudFormation templates.
Practical Scenarios: When to Choose What#
Let’s ground this discussion in real-world decisions.
Choose CloudFormation when: You’re working in a highly regulated environment where every change must be auditable and explicit. You need to support infrastructure code written by people without programming backgrounds. You’re using AWS services that have poor CDK support. You want a single, standardized template format that everyone in the organization understands. You want to avoid the overhead of managing CloudFormation template generation and prefer hand-written templates.
Choose Terraform when: Your organization uses multiple cloud providers and wants consistent tooling and practices across them. You have teams with existing Terraform expertise and training investments. You want to avoid AWS-specific lock-in, even if you’re currently AWS-only. You prefer a tool that’s open-source and community-driven rather than vendor-supported. You want the simplicity of a domain-specific language without the complexity of a full programming language.
Choose CDK when: Your team is primarily composed of software developers comfortable with programming concepts. You want to leverage existing application code patterns and testing frameworks for infrastructure. You’re building complex, dynamic infrastructure that benefits from imperative code and loops. You want the fastest path to infrastructure code for teams already fluent in TypeScript, Python, or another supported language. You’re building Lambda-based or container-based applications and want tight integration with application code.
A practical example: A startup building a serverless API with Lambda, API Gateway, and DynamoDB would likely choose CDK. The developers are already writing TypeScript or Python. They can keep infrastructure and application code together, use the same test frameworks, and move quickly. A financial services company with strict compliance requirements and extensive manual review processes might choose CloudFormation for its explicit, auditable nature. A company running infrastructure across AWS and Google Cloud would choose Terraform for consistency.
Cost, Maintenance, and Long-Term Viability#
There’s no direct cost difference between these tools—they’re all free or open-source. But there are indirect costs worth considering.
Terraform’s open-source nature means no vendor support, though HashiCorp offers commercial support plans. The community is large and active, but maintenance and the pace of feature development depend on community contributions and HashiCorp’s priorities.
CloudFormation and CDK are AWS services with the full backing of Amazon. They’re continuously updated, new AWS services get CloudFormation support quickly, and the documentation is professionally maintained. The risk of the tool becoming unmaintained is essentially zero.
CDK is younger than CloudFormation and Terraform, but it’s been growing rapidly and is clearly a strategic investment for AWS. Major organizations are standardizing on CDK for new projects. It’s unlikely to be abandoned or significantly change direction.
Long-term viability shouldn’t be a primary decision factor—all three tools are here to stay—but it’s worth noting that CloudFormation and CDK benefit from AWS’s commitment and resources.
Testing Your Infrastructure Code#
As infrastructure becomes more complex, testing becomes increasingly important. This is another area where the three tools differ meaningfully.
CDK encourages testing because your infrastructure is code. You can use standard testing frameworks—pytest for Python, Jest for TypeScript—to write unit tests against your constructs. You can test that constructs are instantiated with the right properties, that resources are wired together correctly, and that synthesized CloudFormation looks as expected. Testing infrastructure code with CDK feels natural because you’re using tools you already know.
CloudFormation templates can be tested, but it’s more complex. Tools like cfn-lint can validate syntax. You can create temporary stacks to test behavior, but this is slower and more expensive than CDK’s in-memory testing. Some teams use wrapper tools to test CloudFormation templates more effectively.
Terraform has first-class testing support through test frameworks and community tools, though testing Terraform infrastructure typically requires spinning up real resources, making it slower and more expensive than CDK testing.
Making Your Decision#
The right choice depends on your specific context: your team’s skills, your organization’s structure, your workload characteristics, and your long-term cloud strategy. There’s no universally correct answer.
Start with these questions:
What are your team’s existing skills and language preferences? If you have Python or TypeScript developers, CDK is attractive. If you have infrastructure engineers trained in Terraform, Terraform wins. How critical is multi-cloud support or cloud-agnostic code? If you answer yes, Terraform is essential. Are you building dynamic, code-heavy infrastructure or static, auditable resources? Dynamic infrastructure favors CDK; simple, explicit resources favor CloudFormation. How do you approach testing and quality assurance? If you want to test infrastructure like you test code, CDK shines. What are your compliance and auditability requirements? Highly regulated environments often prefer CloudFormation’s explicitness. Is infrastructure code managed by dedicated teams or by application developers? Dedicated infrastructure teams might prefer CloudFormation or Terraform; application developers might prefer CDK.
One final insight: these aren’t permanent choices. You can use CloudFormation for some stacks and CDK for others. You can migrate between them. You can adopt Terraform while maintaining existing CloudFormation infrastructure. The tools can coexist. Start with the tool that seems like the best fit, build some real experience, and refine from there.
Conclusion#
CDK, Terraform, and CloudFormation are all legitimate, mature approaches to infrastructure as code. CDK is AWS’s modern, developer-friendly option that generates CloudFormation templates from code. Terraform is the multi-cloud standard that prioritizes consistency and portability. CloudFormation is the AWS-native, explicit, fully-featured approach that powers both CDK and serves teams that prefer declarative templates.
The best choice isn’t about which tool is technically superior—they all work well. It’s about which tool aligns with your team’s strengths, your organization’s structure, and your project’s characteristics. A team of application developers building serverless applications on AWS will thrive with CDK. An operations team managing infrastructure across multiple clouds will be most productive with Terraform. A highly regulated organization prioritizing explicit auditability might prefer CloudFormation.
Spend time understanding not just what each tool does, but how it aligns with your team and your problems. The real value of infrastructure as code comes from consistency, maintainability, and the ability to replicate and test your infrastructure reliably. Whichever tool you choose, focus on using it well rather than worrying about whether you chose correctly.