AWS CDK - Finally, Infrastructure That Doesn't Suck

I've been using AWS CDK in production for three years now, and let me tell you - it's been a wild fucking ride. CDK is Amazon's answer to everyone who's ever screamed at their laptop while debugging YAML indentation errors at 2 AM. Instead of wrestling with CloudFormation JSON like it's 2003, you get to write infrastructure in actual programming languages.

Instead of debugging indentation errors in YAML files late at night, you write TypeScript (or Python, Java, C#, Go) and get actual compiler errors when you fuck up. The language support means you can use your IDE's autocomplete instead of memorizing CloudFormation resource properties.

The catch? CDK still deploys through CloudFormation under the hood, so when things break, you're still debugging CloudFormation stack errors. But at least you wrote the code in a language that doesn't make you question your career choices.

How CDK Actually Works (The Parts That Matter)

CDK has three main pieces you need to understand:

Constructs are basically infrastructure Lego blocks. AWS built these at three levels: L1 constructs are just CloudFormation resources with TypeScript wrappers, L2 constructs have sane defaults so you don't have to specify every fucking parameter, and L3 constructs are pre-built patterns like "web app with database." Stick with L2 constructs unless you need something specific.

Apps and Stacks organize your code, though "organize" is generous. One app can have multiple stacks - like one for networking, one for databases, one for your actual application. Keep stacks small or CloudFormation's 500-resource limit will murder your deployment. I was cruising along at 497 resources like an idiot, thinking "I'm basically a DevOps genius." Added 3 more Lambda functions for some bullshit feature request, and boom - deployment dies with a resource limit error. Spent my Saturday morning refactoring stacks instead of drinking coffee like a normal person.

CDK CLI is what actually does the work. Run `cdk synth` to see what CloudFormation shit it generates (always check this first), `cdk diff` to see what's about to break, and `cdk deploy` to pray it works. The CLI converts your code into CloudFormation templates - which is exactly why deployments take forever.

Which Language to Pick (And Why It Matters)

Look, here's the brutal truth about CDK language support that nobody wants to admit:

• TypeScript: Use this. Seriously. It's what AWS built CDK in, so you get new features first, best documentation, and most Stack Overflow answers. Every example online is in TypeScript.
• Python: Fine choice if your team already does Python. Documentation is okay, but you'll spend time translating TypeScript examples. Great for data teams who hate TypeScript.
• Java: If you're stuck in enterprise Java hell, this works. Lots of boilerplate, but at least you get strong typing. Expect verbose code.
• C#/.NET: Decent if you're already .NET shop. AWS actually keeps this up to date, unlike some of their other language bindings.
• Go: Fully supported as of 2025, requires Go 1.18+. Good choice if your team is already Go-focused.

Just pick TypeScript and thank me later. I watched a team spend three weeks trying to make Python CDK work exactly like the docs promised. Spoiler alert: the docs are all TypeScript examples poorly translated to Python. Every Stack Overflow answer, every blog post, every fucking GitHub issue assumes you're using TypeScript.

Fight this choice and you'll be debugging npm dependency hell at 2 AM while your production deployment shits itself and your manager asks why the "simple infrastructure change" is taking 6 hours. Don't be that person.

After three years of deploying CDK apps to production and getting my ass kicked by CloudFormation more times than I care to admit, here's what actually matters versus what's pure AWS marketing bullshit.

CDK promises to bring programming practices to infrastructure, which sounds amazing until reality hits: infrastructure isn't application code, and treating it like application code will bite you in ways that keep you up at night.

Constructs: The Good and The Bullshit

Constructs are CDK's killer feature. You can package up infrastructure patterns and share them like npm packages. This actually works well - I've built constructs for "database with backups" and "Lambda with proper monitoring" that saved weeks of copy-paste hell.

But here's what nobody tells you: building good constructs is hard as hell. Most teams end up with a pile of over-abstracted constructs that hide every important detail, or under-abstracted ones that just create more boilerplate. That perfect construct you built for your specific use case? It'll need major surgery before any other team can use it. Every. Single. Time.

AWS's own constructs are hit or miss. The L2 constructs (like aws-ec2.Vpc) are great - they handle the boring configuration. The L3 constructs (like aws-ecs-patterns.ApplicationLoadBalancedFargateService) make too many assumptions and break when you need anything custom.

Programming Practices That Actually Work

Version Control: This part actually rocks. Infrastructure changes go through PR reviews just like app code. You can see exactly what changed, who changed it, and why. No more "who modified the production security group?" mysteries.

Testing: CDK's testing story is decent. Unit tests verify your constructs generate the right CloudFormation, which catches stupid mistakes. But testing infrastructure logic is weird - you're testing configuration, not behavior. Integration tests that deploy to real AWS are more valuable but cost money and take forever.

IDE Experience: This is where CDK shines. Autocomplete for AWS resource properties is a game-changer. IDE support shows you all the properties for an S3 bucket instead of googling CloudFormation docs. TypeScript catches typos before deployment instead of failing 10 minutes into a stack update.

The catch: none of this fixes the fundamental problem that infrastructure deployment is slow as molasses and error-prone as hell. You still wait 20+ minutes for deployments and spend your evenings debugging gems like "UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS" that tell you absolutely nothing useful.

Deployment Reality Check

cdk diff: This is CDK's killer feature and will save your ass. Shows you exactly what's about to break before you deploy. ALWAYS run this. I've caught dozens of "oh shit, I'm about to delete the production database" moments with cdk diff. But it won't tell you about data impact - deleting an RDS instance just shows up as a casual resource replacement. The diff won't mention you're about to nuke customer data.

Rollbacks: CloudFormation's rollback is both a blessing and a curse. Failed deployments roll back automatically, which prevents partial deployments. But rollbacks can fail too, leaving your stack in UPDATE_ROLLBACK_FAILED state. When that happens, you're debugging CloudFormation in the AWS console during production incidents.

Environment Management: CDK handles dev/staging/prod pretty well. You can pass different parameters and deploy the same code to different accounts. But be careful with stack names and resource naming - it's easy to accidentally deploy prod resources to dev (I learned this the expensive way).

Asset Bundling (AKA Where Things Get Slow)

Lambda Functions: CDK's Lambda bundling is convenient but has gotchas. It automatically packages your function code and dependencies, which works great for simple cases. But bundling a large function takes forever - like 5+ minutes for anything with heavy dependencies. And if bundling fails, the error messages are cryptic.

Pro tip from the trenches: Use esbuild bundling for Node.js - it's like 10x faster than the default webpack hell. Add bundling: { format: BundlingFileType.ESM, target: 'node18', loader: { '.node': 'file' } } to your Lambda construct.

But esbuild is picky as hell about native modules and weird import patterns, so you'll waste hours debugging "Cannot resolve module" errors for packages that bundle perfectly fine with webpack. It's always a tradeoff between speed and "will this actually work?"

Docker Images: CDK can build and push Docker images to ECR during deployment. Sounds great, but now your CDK deployment includes Docker build time. A 15-minute deployment becomes a 30-minute deployment. Better to build images in CI and reference them in CDK.

The Real Problem: Asset bundling makes CDK deployments incredibly slow. What should be a quick configuration change becomes a 20-minute ordeal because CDK rebuilds and uploads assets every time. Plan your coffee breaks accordingly.

CDK's programming model is genuinely better than YAML hell, but the deployment speed will make you question your life choices.