Free preview · Beginner · 22 min read
AWS CDK Mental Model: Infrastructure as Software
Understand where the AWS CDK fits between programming languages, CloudFormation, Terraform, the AWS API and production cloud engineering.
Free preview · Beginner · 22 min read
Understand where the AWS CDK fits between programming languages, CloudFormation, Terraform, the AWS API and production cloud engineering.
The AWS Cloud Development Kit (CDK) lets you define AWS infrastructure in a general-purpose programming language and then deploy that infrastructure through AWS CloudFormation.
The most useful mental model is:
TypeScript / Python / Java / C# / Go / JavaScript
|
v
CDK App
constructs + logic
|
cdk synth
|
v
CloudFormation template
+ asset manifest
|
cdk deploy
|
v
CloudFormation
|
v
AWS resources
CDK is not an alternative AWS control plane. It is a developer-focused way to produce and manage CloudFormation deployments.
CDK is attractive when infrastructure needs real software-engineering techniques:
Instead of copying 500 lines of YAML, you can model an internal platform primitive such as SecureApi or ProductionBucket once and reuse it.
| Question | CloudFormation | AWS CDK |
|---|---|---|
| Authoring model | JSON/YAML templates | General-purpose language |
| Deployment engine | CloudFormation | CloudFormation |
| Reuse | Nested stacks/modules/macros | Constructs, classes, packages |
| Logic | Intrinsic functions/conditions | Language-native logic at synthesis |
| Output | Desired resources | Synthesizes desired resources |
CDK does not eliminate CloudFormation knowledge. Strong CDK engineers understand enough CloudFormation to debug failed stack operations, logical IDs, replacements, rollback behavior and resource policies.
They overlap, but their operating models differ.
CDK -> synthesizes CloudFormation -> CloudFormation manages resource state
Terraform -> Terraform configuration -> Terraform state maps resources
Do not pick a tool because its syntax looks nicer. Consider team language skills, AWS-only vs multi-cloud requirements, existing state, governance, deployment model and ecosystem.
A common mistake is to write huge CDK programs full of hidden side effects. Infrastructure code should still be predictable.
Prefer:
const app = new cdk.App();
new NetworkStack(app, 'Network', { env });
new ApplicationStack(app, 'Application', { env });
app.synth();
Avoid synthesis-time code that mutates cloud resources, calls random external APIs or depends on undocumented developer-machine state.