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.