Why TypeScript for Infrastructure as Code

For the first decade of IaC, the field converged on declarative formats: AWS CloudFormation (JSON/YAML), Terraform (HCL), Kubernetes (YAML). Declarative is powerful — you describe desired state and the tool converges to it. But as infrastructure complexity grows, the limits become painful:

• No abstraction. Want to reuse a "VPC + private subnets + NAT Gateway" pattern across 20 stacks? Copy-paste the YAML, or learn the template/module system — which approximates the language features you already have in Python or TypeScript.
• No unit tests. You can't write test('VPC has 3 private subnets', () => ...) against HCL.
• No IDE support. YAML doesn't autocomplete resource ARNs, type-check property values, or refactor names safely.
• Loops and conditionals are second-class. Terraform 0.13 finally got for_each; CloudFormation's !If / !FindInMap / !Sub are YAML gymnastics.
• Scale. A 10k-line CloudFormation template is a maintenance nightmare. A 10k-line TypeScript codebase with proper modules is standard.

Enter CDK

The AWS Cloud Development Kit (CDK) was released publicly in 2019. The insight: why invent a DSL for infrastructure? Just let engineers write real code. The CDK synthesises that code to CloudFormation at deploy time. The engineer never sees the CloudFormation — they work with constructs.

// Three lines of TypeScript define a full production S3 bucket
const bucket = new s3.Bucket(this, 'DataBucket', {
  versioned: true,
  encryption: s3.BucketEncryption.S3_MANAGED,
  removalPolicy: RemovalPolicy.RETAIN,
});

The equivalent CloudFormation is 30+ lines of JSON. The CDK version:

• Autocompletes in your IDE
• Type-checks removalPolicy against the enum — typos are compile errors
• Can be used in a for loop, inside a class, imported from a package
• Can be unit-tested

The Tool Landscape

TypeScript is first-class in all four. The AWS CDK team internally uses TypeScript. Pulumi was written in Go but the TypeScript SDK is the most used. When in doubt, TypeScript.

The Construct Model

The central abstraction across CDK, Pulumi components, and cdk8s is the construct: a reusable, composable piece of infrastructure.

Three levels in CDK:

You compose L2 and L3 constructs to build your own L3s — reusable "Company Standard ECS Service" or "Regulated VPC" that embeds your organisation's security policies.

Why TypeScript Specifically

CDK supports five languages. TypeScript wins because:

1. First-class. The AWS CDK source is TypeScript; Python/Java/Go bindings are generated from it via JSII. TypeScript always gets features first.
2. Static types + structural subtyping. CloudFormation resource schemas are mapped to TypeScript interfaces — you get property-level type checking.
3. npm / Node ecosystem. The construct library ecosystem lives on npm; versioning, publishing, and sharing constructs is standard Node tooling.
4. Familiarity. Most frontend engineers already know JS/TS. Most DevOps engineers know Python. Either reach works.
5. JSII. Pulumi, CDKTF, and cdk8s all follow CDK's lead — TypeScript is the authoring language for libraries that are then JSII-compiled for other languages.

What This Course Covers

The next lesson gives enough TypeScript to be productive in CDK without assuming JS expertise. From there we build with the AWS CDK, write tests, build a CDK Pipeline, then look at Pulumi and cdk8s for the beyond-AWS use cases.

By the end you will be able to write, test, and deploy real infrastructure in TypeScript — and read the growing corpus of CDK/Pulumi open-source constructs confidently.