AWS CDK
An IaC framework that lets you define AWS infrastructure using programming languages like TypeScript and Python, deploying as CloudFormation templates
Overview
AWS Cloud Development Kit (CDK) is an open-source Infrastructure as Code (IaC) framework that lets you define AWS infrastructure using familiar programming languages (TypeScript, Python, Java, C#, Go). CDK code is internally synthesized into CloudFormation templates and deployed via CloudFormation. Three levels of constructs - L1 (1:1 CloudFormation resource mapping), L2 (high-level abstractions with built-in best practices), and L3 (multi-resource patterns) - enable building production-quality infrastructure in just a few lines of code.
Choosing Between L1, L2, and L3 Constructs
CDK constructs are organized into three levels by abstraction. L1 constructs (CfnXxx) are direct wrappers around CloudFormation resources, providing access to every configurable property. They are needed for new resource types or properties not yet supported by L2. L2 constructs are the most commonly used level; for example, creating an s3.Bucket automatically applies encryption, public access blocking, and versioning by default, and exposes convenience methods like bucket.grantRead(lambdaFunction) that generate the correct IAM policies automatically. L3 constructs (patterns) like LambdaRestApi build multiple resources (Lambda + API Gateway + IAM role) in one go, dramatically reducing boilerplate for common architectures. In practice, the recommended approach is to primarily use L2 constructs and supplement with L1 escape hatches (via node.defaultChild) only for fine-grained settings that L2 does not expose. When evaluating a new L3 construct, verify that its opinionated defaults align with your requirements - otherwise, composing L2 constructs yourself gives you more control.
Strengths and Caveats of IaC in Programming Languages
CDK's fundamental differentiator is using general-purpose programming languages (TypeScript, Python, Java, C#, Go) instead of declarative DSLs. This unlocks the full power of programming - loops, conditionals, functions, class inheritance, generics, and package managers - making it easy to reuse complex infrastructure patterns, generate dynamic configurations, and enforce organizational standards through shared construct libraries. For example, you can create a CompanyBucket class that extends s3.Bucket with your organization's encryption, logging, and tagging policies baked in, then publish it as an internal npm package. HashiCorp Terraform, the most common alternative, uses its own declarative language (HCL), which provides higher code predictability and a mature multi-cloud ecosystem. CDK also has cdk diff for previewing changes, but the flexibility of programming languages carries a higher risk of unintended resource changes compared to Terraform's plan command. For multi-cloud requirements, Terraform is the practical choice, but for AWS-only environments, CDK's productivity advantage is substantial. IaC books on Amazon cover this systematically.
Stack Splitting and Testing Strategies
The first decision when adopting CDK in practice is stack splitting strategy. Putting all resources in a single stack leads to long deployment times, risks one change affecting all resources, and can hit CloudFormation's 500-resource limit. The recommended approach is splitting stacks by responsibility - networking (VPC, subnets, NAT gateways), data stores (RDS, DynamoDB, S3), and compute (Lambda, ECS, API Gateway) - and loosely coupling inter-stack dependencies via SSM Parameter Store or CloudFormation exports. Avoid direct cross-stack references for resources that might be replaced, as CloudFormation cannot update an export that is imported by another stack. For testing, CDK provides multiple layers of verification: cdk-nag runs security and compliance checks against rules like AWS Solutions and HIPAA, the Assertions module enables both snapshot tests (detecting unintended changes) and fine-grained tests (asserting specific resource properties), and integration tests can deploy to a real AWS account and validate behavior. Running these tests in CI/CD pipelines ensures infrastructure code quality is continuously verified before any deployment reaches production.