CDK & SAM

Infra in code; serverless; when to use which.

Intermediate30 min · lesson 5 of 15

For teams that want the power of a programming language in their infrastructure, the AWS CDK and SAM sit on top of CloudFormation. They keep IaC’s safety while adding abstraction and developer ergonomics.

The CDK: infrastructure in code

The AWS Cloud Development Kit lets you define infrastructure in a real programming language (TypeScript, Python, Java, Go), which it synthesizes into CloudFormation templates — so you get loops, conditionals, functions, and unit testing for your infrastructure, plus the deploy-time safety of CloudFormation underneath. Its constructs are reusable components at three levels: L1 map directly to CloudFormation resources, L2 add sensible defaults and best practices, and L3 (patterns) bundle whole architectures. This means you can encode organizational standards once as a construct and reuse them, dramatically reducing boilerplate while keeping every deployment governed by CloudFormation’s change sets and rollback.

CDK synthesizes CloudFormation
// Define infra in code — with real language features and reusable constructs.
const bucket = new s3.Bucket(this, 'AppBucket', {
encryption: s3.BucketEncryption.KMS_MANAGED, // L2 defaults enforce best practice
versioned: true,
removalPolicy: RemovalPolicy.RETAIN,
});
new s3deploy.BucketDeployment(this, 'Assets', { destinationBucket: bucket, sources: [...] });
// cdk synth → generates a CloudFormation template
// cdk deploy → deploys it (change sets + rollback still apply)

SAM and choosing an IaC tool

AWS SAM (Serverless Application Model) is a CloudFormation extension with concise syntax for serverless apps — a few lines define a Lambda, its API Gateway trigger, and a DynamoDB table, and the SAM CLI supports local testing. For a DevOps engineer the choice among CloudFormation (declarative YAML/JSON), CDK (imperative code), and SAM (serverless-focused) depends on the team and workload: CDK for complex, DRY infrastructure with programmatic logic; SAM for serverless; plain CloudFormation or Terraform where declarative templates suffice. All ultimately provision through CloudFormation’s safe, auditable engine, so the safety story is consistent — the differences are ergonomics and abstraction, not the underlying guarantees.

IaC options on AWS
1CloudFormation
declarative YAML/JSON templates
2CDK
code (TS/Py) → synthesizes CFN
3SAM
concise serverless, local testing
4all → CloudFormation engine
change sets + rollback
Pick the ergonomics that fit the team; CDK/SAM synthesize to CloudFormation, so the safety guarantees are the same underneath.
CDK still deploys real infrastructure — review the synth
Because the CDK feels like writing an app, it is easy to forget it provisions real, costly, stateful resources. Review the synthesized CloudFormation (cdk diff) before deploying, keep removal policies on stateful resources set to retain, and treat CDK code with the same care as any production infrastructure change.