AWS CDK: Infrastructure as Real Code

CloudFormation templates are YAML. YAML is fine for short configs. By the time a template is 800 lines, with 14 IAM policies, three Lambda functions, four environment-specific parameters, and nested copy-paste, YAML stops being fine.

The AWS Cloud Development Kit (CDK) is the answer: define infrastructure in TypeScript, Python, Java, C#, or Go. Run a command. CDK generates a CloudFormation template, then deploys it.

The Core Idea

In CDK, infrastructure is just code:

const bucket = new s3.Bucket(this, 'UploadsBucket', {
  versioned: true,
  encryption: s3.BucketEncryption.S3_MANAGED,
  lifecycleRules: [{ expiration: Duration.days(90) }],
});

Three things matter about this:

• It is a programming language. You can use loops, conditionals, classes, npm packages;
• It produces CloudFormation. Under the hood, CDK synthesizes a template. Everything CloudFormation gives you (drift detection, change sets, rollback) still applies;
• The defaults are sane. A new Bucket() call in CDK comes with encryption enabled, public access blocked, and reasonable lifecycle defaults. Plain CloudFormation makes you spell all of that out.

Constructs: The Building Blocks

CDK code is composed of constructs, organized in three levels:

• L1 constructs — one-to-one with CloudFormation resources. Prefixed with Cfn (e.g., CfnBucket). Verbose but complete;
• L2 constructs — curated, opinionated wrappers around L1. The everyday choice (e.g., Bucket, Function, Table);
• L3 constructs, also called patterns — pre-built combinations of multiple resources. For example, ApplicationLoadBalancedFargateService creates a Fargate task, an ALB, security groups, and target groups in one call. Most CDK code lives at L2. L3 is gold for common patterns. L1 is the escape hatch for niche cases.

The CDK Workflow

A standard CDK loop looks like this:

• cdk init — scaffold a new project;
• Write or edit constructs;
• cdk synth — generate the CloudFormation template, see exactly what will be deployed;
• cdk diff — compare against what is currently deployed;
• cdk deploy — push the change up;
• cdk destroy — tear it down. The synth and diff steps are the equivalent of CloudFormation change sets. Same protection, friendlier output.

CDK vs SAM vs Plain CloudFormation

When to reach for what:

• Plain CloudFormation — simple stacks, organizational standards that mandate YAML/JSON, or learning the underlying primitives;
• SAM — a Lambda + API Gateway + DynamoDB serverless app, especially with local testing via sam local;
• CDK — anything that benefits from reuse, loops, or sharing logic across stacks. Most multi-environment, multi-region work. A team that adopts CDK rarely goes back to writing CloudFormation by hand. The flip side: debugging a CDK error sometimes means reading the synthesized template, and the abstraction can hide what is actually happening.

Common Patterns

Two patterns show up everywhere in CDK codebases:

• Environment-aware stacks. A loop creates Dev, Staging, and Prod stacks from the same construct, parameterized differently;
• Shared construct libraries. Internal npm or PyPI packages that ship your company's standard "secured bucket" or "compliant Lambda" so every team starts from the same baseline. This is the leverage CDK provides — your security team can ship a CompliantBucket construct, every team uses it, and the company-wide baseline updates with one package version bump.

For the Exam

For the Developer Associate exam, you need to know:

• CDK supports TypeScript, JavaScript, Python, Java, C#, and Go;
• CDK synthesizes CloudFormation templates and deploys them via CloudFormation;
• cdk bootstrap sets up an S3 bucket and IAM roles in your account that CDK uses for asset uploads — required once per account-region;
• The three construct levels (L1, L2, L3) and what they are for. You are unlikely to be asked to read CDK code on the exam. You are very likely to be asked which IaC tool fits a given scenario.