Infrastructure as Code for Beginners: CDK vs Terraform

If you have ever clicked through a cloud console to spin up a server, set up a database, and wire together a handful of networking rules — only to be asked to do it all again in a second environment — you have felt the pain that Infrastructure as Code (IaC) solves. Instead of manually provisioning resources, you describe them in files, commit those files to version control, and let tooling create, update, and destroy your infrastructure predictably.

Two names dominate the beginner conversation: AWS CDK (Cloud Development Kit) and Terraform. Both are excellent. Both are widely used in production. But they take meaningfully different approaches, and the right choice depends on your team, your cloud, and how you like to work. This guide breaks it all down.

What Infrastructure as Code Actually Means

At its core, IaC replaces manual, click-driven setup with declarative definitions. You write down the desired state of your infrastructure — "I want an S3 bucket, a Lambda function, and an IAM role" — and the tool figures out the API calls needed to make reality match your description.

The benefits are immediate and compounding:

• Reproducibility — spin up identical staging and production environments from the same code.
• Version control — every infrastructure change is a diff you can review, revert, and audit.
• Collaboration — teammates propose changes through pull requests instead of Slack messages.
• Disaster recovery — if a region goes down, you can recreate everything from your repository.

Once you have experienced deleting an entire environment and rebuilding it with one command, going back to the console feels reckless.

Meet Terraform

Terraform, created by HashiCorp, is the veteran of the space. It uses a domain-specific language called HCL (HashiCorp Configuration Language). HCL is declarative — you describe what you want, not how to build it.

Here is a minimal example that creates an AWS S3 bucket:

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-beginner-iac-bucket"
}

resource "aws_s3_bucket_versioning" "versioning" {
  bucket = aws_s3_bucket.my_bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

Terraform's biggest strength is that it is cloud-agnostic. Through its provider ecosystem, the same tool manages AWS, Azure, Google Cloud, Cloudflare, Datadog, GitHub, and hundreds of other platforms. If your organization is multi-cloud, or if you want a single tool to rule everything from DNS to databases, Terraform is compelling.

Terraform tracks what it has created in a state file. This file maps your configuration to real-world resources. Managing that state — usually in a remote backend like an S3 bucket with locking — is one of the first "grown-up" skills you will learn.

Meet AWS CDK

The AWS Cloud Development Kit takes a different philosophy: use a real programming language. With CDK you write TypeScript, Python, Java, C#, or Go, and the CDK synthesizes your code into a CloudFormation template that AWS then deploys.

Here is the same S3 bucket in CDK using TypeScript:

import * as s3 from 'aws-cdk-lib/aws-s3';
import { Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';

export class MyStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    new s3.Bucket(this, 'MyBucket', {
      bucketName: 'my-beginner-iac-bucket',
      versioned: true,
    });
  }
}

Notice that versioned: true is a single property, and CDK expands it into the underlying CloudFormation configuration for you. Because you are writing real code, you get loops, conditionals, functions, classes, unit tests, IDE autocomplete, and inline documentation. For developers who already think in code, this feels natural and powerful.

The catch: CDK is AWS-first. While a variant called CDKTF (CDK for Terraform) exists, the core CDK experience is built around AWS and CloudFormation. If you live entirely inside AWS, that is a feature, not a limitation.

Head-to-Head Comparison

Let's put the two side by side on the dimensions that matter most to a beginner.

Language and Learning Curve

Terraform's HCL is small and purpose-built. You can become productive in a day or two, and its declarative nature means there is less to reason about. CDK requires you to know a general-purpose programming language, but if you already do, you may feel more at home immediately. The trade-off is that CDK's abstraction can hide what is really happening, which occasionally makes debugging harder.

Cloud Support

Terraform wins on breadth. One tool, one workflow, hundreds of providers. CDK is deeply optimized for AWS and offers higher-level constructs that encode AWS best practices out of the box.

State Management

Terraform requires you to manage state files explicitly. CDK offloads state to CloudFormation, which AWS manages for you — one less thing to worry about, at the cost of being tied to CloudFormation's quirks and occasionally slow deployments.

Abstraction and Reuse

CDK's constructs let you package reusable infrastructure patterns as classes. Terraform has modules, which serve a similar purpose. Both are good; CDK's approach feels more natural to programmers, while Terraform's modules are simpler and more explicit.

Community and Ecosystem

Terraform has a massive, mature community and the Terraform Registry full of ready-made modules. CDK's community is growing fast and benefits from AWS's official backing and the Construct Hub.

Practical Advice for Choosing

Here is the honest, no-hype guidance:

Choose Terraform if:

• You are multi-cloud or expect to be.
• You want the broadest possible ecosystem and job-market relevance.
• Your team prefers a simple, declarative config over full programming.
• You need to manage non-cloud resources (SaaS, DNS, monitoring) alongside infrastructure.

Choose CDK if:

• You are all-in on AWS.
• Your team is made up of developers who want to use their existing language skills.
• You value high-level abstractions and want to write unit tests for your infrastructure.
• You want tighter integration with AWS's native tooling.

A pragmatic middle path: many teams start with Terraform because the concepts transfer everywhere, then adopt CDK later for AWS-heavy application stacks. There is no wrong answer, and learning one makes the other easier.

Getting Started Tips

Regardless of which tool you pick, these habits will save you pain:

1. Commit everything to Git from day one. Your infrastructure code deserves the same discipline as application code.
2. Never edit resources by hand in the console. Manual changes cause "drift" — a mismatch between your code and reality.
3. Use remote state and locking (Terraform) or separate stacks per environment (CDK) to avoid conflicts.
4. Always run a plan/diff before applying. terraform plan and cdk diff show you exactly what will change. Read the output.
5. Start small. Provision one bucket, then one function, then wire them together. Do not try to codify your entire architecture on day one.
6. Tear down what you build in tutorials (terraform destroy / cdk destroy) to avoid surprise bills.

Frequently Asked Questions

Is CDK or Terraform better for absolute beginners? Terraform tends to be gentler because HCL is small and declarative, and the concepts apply to every cloud. But if you already know Python or TypeScript and only use AWS, CDK may feel more intuitive.

Do I need to know CloudFormation to use CDK? Not to start, but a basic understanding helps enormously when debugging. CDK compiles down to CloudFormation, so errors often surface in CloudFormation terms.

Can I use both in the same organization? Yes, and many teams do. It is common to see Terraform managing foundational, cross-cloud infrastructure while CDK handles AWS application stacks. Keep clear boundaries so the two tools never manage the same resource.

What is a state file and why does it matter? Terraform's state file records which real resources correspond to your configuration. It is critical — losing or corrupting it can make Terraform lose track of your infrastructure. Store it remotely with locking enabled. CDK avoids this by delegating state to CloudFormation.

Is Terraform still free? The Terraform CLI is no longer open source. On August 10, 2023, HashiCorp changed its license from the Mozilla Public License (MPL) v2.0 to the Business Source License (BSL) v1.1 — which is source-available but not OSI-approved open source and restricts competitive commercial use. This change prompted the creation of OpenTofu (originally OpenTF), a fully open-source fork under MPL 2.0, now governed by the Linux Foundation. The Terraform CLI remains free for most individual and team use cases that are not competitive with HashiCorp; OpenTofu is free and open source for all uses.

How long until I am productive? Expect a few days to grasp the fundamentals and a few weeks to feel comfortable with real projects, state management, modules or constructs, and CI/CD integration. The concepts transfer, so your second tool will come much faster than your first.

Final Thoughts

Infrastructure as Code is one of the highest-leverage skills you can learn in modern cloud engineering. Whether you reach for Terraform's cloud-agnostic breadth or CDK's programmer-friendly power, you are trading fragile manual clicking for reproducible, reviewable, version-controlled infrastructure. Pick one, build something small, tear it down, and build it again. The muscle memory you develop will serve you across every cloud and every tool for years to come.

Sources

• HashiCorp Adopts Business Source License (Official Announcement)
• OpenTofu — Open-Source Terraform Fork (Official Site)
• AWS CDK Developer Guide
• Terraform Documentation