CDK First Thoughts

At re:Invent last year I attended a talk on the CDK out of curiosity and because I had some time to kill after not making it to another session. I was intrigued by what I learned in terms of the cross-language support and how that was handled, but I had a hard time seeing how it would work as a replacement for CloudFormation.

Then I tried using it.

I chose python as my language simply because that’s what I’ve been using lately in some other projects, and I wanted to keep working on that skill set. I also had some libraries I knew I’d want to bring in later on. Aside from the documentation being pretty confused and, at times, inaccurate, I ended up liking it quite a bit. In 200 lines of python I was able to do what takes hundreds more lines in pure CloudFormation, plus I had a level of logic and conditionals that simply aren’t practical or possible otherwise.

So I whipped up a little framework for my personal projects that I’ve used to build out static sites (such as this one). It reads a YAML file and will build out my:

  • S3 bucket
  • a CloudFront distribution
  • ACM Certificate with appropriate names
  • builds a Route53 zone and populates it with everything I need
  • sets up logging for all of the above in a centralized place
  • adds some SSM Parameter Store items for use in other tools

All with just a bit of wrapper scripting. Most of that is certainly possible with CloudFormation, but the DNS records are where this really shined as I needed a way to supply an arbitrary set of records to handle mail and other non-AWS things in a config and still have it all managed from a single tool.

The only ‘manual’ steps I had to take were:

  • add the NS records to my registrar
  • approve the ACM requests (this can be done in another way, but not with how my domains are built)

I’ll continue to update with examples and lessons learned as I go, but I think I’ll be sticking with the CDK for my infrastructure building for a while.