The Amazon Web Services Cloud Development Kit (AWS CDK) and Terraform are both widely used infrastructure as code (IaC) tools, but their approaches to infrastructure automation have distinct differences, which result in different strengths and weaknesses.
This article explores the differences between CDK and Terraform to help you determine which approach best fits your team.
(Note that Terraform also has its own [CDK ], but it's not as widely used. In this article, mentions of *CDK* refer to *AWS CDK*.)
Language and Syntax AWS CDK and Terraform approach language and syntax very differently.
Because AWS CDK supports multiple programming languages, developers can use languages they're already familiar with. This reduces the learning curve, especially for those who have strong backgrounds in software development. Teams can also reuse tooling, libraries, and coding standards when building infrastructure, making AWS CDK more intuitive for those already experienced in application development.
For example, the code to create an S3 bucket with TypeScript includes the following:
export class TestCdkStack extends cdk . Stack {
constructor ( scope: Construct, id : string, props?: cdk.StackProps ) {
super ( scope, id , props );
const bucket = new s3 . Bucket ( scope, 'Bucket' , {
blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
encryption: s3.BucketEncryption.S3_MANAGED,
enforceSSL: true,
versioned: true,
removalPolicy: cdk.RemovalPolicy.RETAIN
} )
}
}
Those familiar with TypeScript will find the syntax straightforward as it's similar to creating any class with an object in that class.
Terraform, on the other hand, uses a domain-specific language called HCL. HCL is simple and built for defining infrastructure, but it requires learning a new syntax. Granted, HCL is highly readable and designed to emphasize clarity. This makes it approachable for operations teams or those who prefer declarative approaches over imperative coding.
A bucket similar to the AWS CDK example above (with fewer configurations) looks like this:
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 4.16"
}
}
required_version = ">= 1.2.0"
}
provider "aws" {
region = "us-west-2"
}
resource "aws_s3_bucket" "test_bucket" {
bucket = "test_bucket"
}
resource "aws_s3_bucket_public_access_block" "test_bucket" {
bucket = aws_s3_bucket.test_bucket.id
block_public_policy = true
}
resource "aws_s3_bucket_versioning" "versioning_example" {
bucket = aws_s3_bucket.example.id
versioning_configuration {
status = "Enabled"
}
}
Programming Model AWS CDK employs an object-oriented programming model. Cloud resources are represented as classes, and they can be composed using methods and properties. Developers can use conditional logic, loops, and variables, which gives them a high degree of flexibility in how infrastructure is defined. This allows for advanced infrastructure patterns and custom abstractions that are not always as easily achievable with Terraform's model.
Using the AWS CDK code above, it's easy to write a method for determining a bucket name:
const bucket = new s3.Bucket(scope, ‘Bucket’, {
bucketName : this .createBucketName(id),
…
})
}
createBucketName = ( id: string ) => {
//any custom logic to return the bucket name
}
Terraform, being declarative, focuses on describing the desired state of infrastructure rather than the steps to achieve it. This doesn't mean Terraform lacks conditional logic or loops; however, writing complex logic may sometimes require adding plugins . This is because HCL syntax lends itself to having resources declared in a simple, ordered manner as opposed to complex functions. Though Terraform is less flexible when applying complex logic, its simplicity ensures that configurations are predictable and easy to manage.
With the HCL code from the previous example, a conditional statement can be written like so:
variable "bucket_name" {
...
}
resource "aws_s3_bucket" "test_bucket" {
bucket = var .bucket_name != "" ? var .bucket_name : "test_bucket"
}
For straightforward infrastructure definition, Terraform's model reduces complexity and avoids the pitfalls of overly intricate logic that can lead to hard-to-debug configurations. But if you need more advanced logic or custom abstractions or prefer an imperative programming style, AWS CDK's object-oriented model will feel more natural.
Cloud Provider Support An important caveat for AWS CDK is that it's built for AWS cloud services. This narrows its use case to those building and managing AWS infrastructure.
If you're focused solely on AWS, CDK's deep integration with AWS CloudFormation tailored to AWS services makes it a strong choice for your team. However, switching cloud providers from AWS often means more work since the IaC will have to be rewritten or translated. Even though the AWS support team is available to help in such scenarios, the cost of making the switch can be high.
In contrast, Terraform is known for its vast support across cloud providers. It offers official and community-backed providers for a wide range of platforms, like AWS, Google Cloud, Azure, and even on-premises solutions. This makes Terraform a go-to solution for teams with multicloud strategies or hybrid architectures or teams that wish to remain flexible enough for future migration plans.
Infrastructure Abstraction Since AWS CDK aims to simplify how developers write IaC with their programming language of choice, it provides essential "building blocks" for common infrastructure patterns with minimal boilerplate code. As Jay V., founder of the IaC tool SST, explains , "Your CDK constructs generate a CloudFormation template (JSON), that is then sent to CloudFormation (the service) and it deploys your infrastructure. It's important to understand that this is a two step process." Using AWS CDK's higher-level abstractions means developers can focus more on solving business problems with common programming languages instead of managing underlying infrastructure details and looking under the hood.
Terraform provides a more direct mapping to cloud resources, giving users full control over each configuration. However, this can result in what developers perceive as more "boilerplate" code. For example, in Terraform, creating an S3 bucket requires declaring what cloud provider you're using and the region in which your bucket will be deployed. Creating any additional AWS resource to access that bucket requires creating a "permission" resource that links the two. In contrast, AWS CDK abstracts the permissions away by automatically granting permissions to resources under the same construct. Terraform users require more detailed knowledge of cloud services, like how to set permissions for each resource. This makes Terraform ideal for teams that require fine control and greater granularity over their infrastructure components.
State Management AWS CDK relies on AWS CloudFormation for state management. Since the state of the infrastructure is reflected in the CloudFormation template and is automatically managed by AWS CloudFormation, developers do not need to manually handle state files or worry about state locking.
However, manually configuring resources on the cloud after it's been deployed can create *drift*, which are differences between actual resources and the code used to deploy them. And though AWS has provided a custom solution for detecting drift, doing so requires extra work that comes at the cost of higher-level abstraction.
Terraform, on the other hand, has flexible state-management capabilities. It allows the state to be stored locally or in remote backends like S3 or Terraform Cloud, with state locking to prevent race conditions in concurrent environments. Terraform also has a built-in solution for drift detection, making it highly versatile when it comes to managing infrastructure state across different environments and teams.
Testing and Validation AWS CDK supports unit testing of infrastructure code using traditional testing frameworks, like Jest for TypeScript or pytest for Python. Complex functions and logic can therefore be tested just like any code written for applications. AWS also provides an assertion library to ensure the infrastructure generated matches the expected output.
To test the stack written in previous examples, you can import the library and test it like so:
import { Template } from 'aws-cdk-lib/assertions' ;
…
const stack = new TestCdkStack( /* ... */ );
const template = Template.fromStack(stack)
template.templateMatches({
Resource : {
… /// Expected output here
}
})
The `Template` library has a `templateMatches` method that compares the `stack` object with your expected output. The library makes it fairly easy to test what the stack contains and creates before deployment.
The most commonly used method for testing Terraform is its built-in validation through the `terraform plan` command, which shows the changes that will be made to infrastructure before deployment. For those more familiar with assertion testing, Terraform also includes validation methods that create "test-specific, short-lived resources" for verifying outputs that are more fine-grained than the `terraform plan` command.
Here's an example for checking that the S3 bucket name from the previous examples matches what's expected:
variables {
bucket_prefix = "test"
}
run "check_bucket_name" {
command = plan
assert {
condition = aws_s3_bucket.test_bucket.bucket == "test_bucket"
error_message = "S3 bucket name did not match expected"
}
}
The `check_bucket_name` program runs to ensure that the condition tested (that the bucket that's created is named `test_bucket`) passes. If not, an `error_message` is thrown with the reason the assertion failed.
Learning Curve and Developer Experience AWS CDK has a relatively easy learning curve since developers already familiar with supported programming languages can simply import the `aws-cdk` library into their project. AWS CDK can be challenging for those new to cloud infrastructure, but the challenge stops at learning how each cloud service works: AWS CDK's emphasis on providing a good developer experience means devs can work comfortably with a language they already know.
Though Terraform has a steeper initial learning curve due to HCL and its declarative model, once users grasp the fundamentals, the consistent experience across cloud providers is a great advantage. HCL syntax is also fairly easy to learn, and unlike with AWS CDK, switching cloud vendors is a more pleasant and straightforward experience with Terraform.
This means Terraform offers a better developer experience for those working with multicloud strategies and those who want to ensure their infrastructure can be rewritten using the same language. For Terraform users, it's "learn once, deploy anywhere."
Integration with Existing Workflows You can use AWS CLI commands to deploy AWS CDK applications. As with other AWS services, custom scripts for AWS CDK make it simple to integrate into existing workflows. Assuming the initial pipeline configurations are already set up, you can install the AWS CLI tool and use it to easily build and deploy applications with the `cdk deploy` command. You can also integrate other CLI commands to authenticate, test, and contextualize the stack for the pipeline to run.
Similarly to AWS CDK, Terraform provides a standard workflow that can be automated via Terraform CLI commands. Terraform also provides a wide range of flags to ensure that any automated builds and deployments are as streamlined as possible.
Ecosystem and Third-Party Support The additional services available through AWS's growing ecosystem make AWS CDK a stable platform for building IaC. Since AWS CDK is an open source project , anyone with a GitHub account can inspect, modify, and contribute to the project directly or request third-party support by submitting issues or discussion questions. Community forums like the AWS subreddit or the unofficial Discord channel also have members willing to help. Furthermore, useful tools like the AWS Construct Library supply reusable constructs, allowing developers to plug and play with common infrastructure patterns.
Terraform also has an ecosystem that includes a vast library of providers and modules covering a broad range of infrastructure components linked in its own registry . Terraform is four years ahead of AWS CDK, and its long-standing presence in the IaC space has led to an abundance of third-party resources, modules, and plugins, along with its own community forum . Most of what you want to accomplish with Terraform has likely already been written as libraries. Like AWS, Terraform also has its own subreddit and GitHub page for third-party support.
Performance and Scalability AWS CDK's object-oriented model of programming means each stack is paired to individual classes that can be modified. Scaling simply means adding more objects to the stack. And since AWS CDK uses AWS CloudFormation, you can rest assured that your infrastructure will translate to something modular, readable, and therefore scalable. However, AWS CDK's abstraction comes at the cost of slower provisioning time for very large stacks. Still, there are recommended configurations that speed up the deployment process.
Terraform is designed to handle large, complex infrastructures efficiently. Due to its declarative model, each resource is written in a way that's modular, making it easy to scale. It supports parallel resource creation by default, which speeds up the provisioning process, and scales effectively with large state files.
In fact, many large corporations, like Slack, have documented how they deployed large infrastructure and scaled with Terraform, proving that Terraform is a trustworthy and efficient solution. Lower-level abstractions also mean less time to deploy since Terraform does not have to translate its code into a different format for deployment.
Deployment and Provisioning AWS CDK generates AWS CloudFormation templates and relies on CloudFormation for deploying and provisioning infrastructure. As mentioned, you can integrate AWS CLI commands into your pipeline, but you can also define how the deployment pipeline works using AWS CDK itself. You can even set up the AWS CodePipeline for deployment. Important to note is that all these deployment methods go through the same process; outside of configuring how the deployment is done, your code's deployment speed is on AWS and not you.
Unlike AWS CDK, Terraform directly interacts with cloud provider APIs to provision resources. Not having to turn any Terraform code into a CloudFormation template means speedier builds and deployments due to fewer steps. This direct interaction also allows for faster, more flexible provisioning across multiple platforms.
For those who prefer a custom user interface for managing infrastructure deployments, Terraform HCP is a great addition. It integrates well with version control systems and allows you to manage remote state storage, set up role-based access control, and more. If you want a more fully integrated solution, you'll find HCP Terraform a useful alternative.
Version Control and Collaboration According to AWS CDK documentation , version control should be done via "your own automated pipeline to build and release new AWS CDK construct versions." This means developers should rely on their own existing version control and collaboration tools, like GitLab or BitBucket. Since AWS CDK uses general-purpose programming languages, developers can also take advantage of existing language-based collaboration tools like package management systems (*eg* npm or PyPI).
Collaboration on an AWS CDK project will therefore look similar to working together on any other application in an existing version control system. As mentioned before, developers should be mindful of manually configuring cloud services outside of their version control system and causing state drift.
Similarly, Terraform documentation also recommends using existing version control systems. To prevent teammates from stepping on one another's toes, Terraform provides features like remote state storage and state locking, which work together to prevent possible state drift. Its HCP Terraform software also provides extra features for integrating with existing version control systems.
Use Cases and Best-Fit Scenarios If you're using AWS, not planning on switching cloud providers, and prefer sticking with your preferred programming languages and models, AWS CDK is ideal. Teams that share a common programming language for building applications will especially find AWS CDK fitting. In such scenarios, the lower ramp-up and maintenance time will increase overall productivity for the team.
However, Terraform is better suited for multicloud strategies, hybrid infrastructures, and teams who foresee switching cloud providers in the future. While developers unfamiliar with HCL may need some time to learn it, switching cloud providers with Terraform simply means changing the code rather than rewriting the entire infrastructure. For teams who work with multiple programming languages, Terraform may also be the natural choice since its declarative model is easier to pick up compared to other languages.
Conclusion AWS CDK and Terraform are both powerful IaC tools with unique strengths. As you evaluate which tool fits your needs, consider your team’s expertise, cloud provider requirements, and the complexity of your infrastructure.
Whether you use AWS CDK or Terraform, it only helps to get computing resources in place. For better visibility into your Kubernetes services across multiple environments, check out mogenius . The free plan lets you deploy and troubleshoot applications on any Kubernetes cluster, and it offers intuitive onboarding.
