We will look at CDK escape hatches, including the ultimate one: exporting to independent CloudFormation.
In the previous article, we built a CDK construct. However, we also want the solution to be functional on its own as a CloudFormation template. This way, you do not have to incorporate the solution into your stack. You deploy a new one and point to the existing SNS topic you use for CloudWatch Alarm notification. We do not want to write CloudFormation from scratch but to reuse the CloudFormation that CDK produces. In this article, we will look at how to convert CDK to clean CloudFormation without CDK metadata and the weird naming that CDK produces. Along the way, we will learn some really useful CDK tricks.
Why convert to CloudFormation and ship independently of CDK?
There are multiple reasons why people may prefer exported CloudFormation over CDK.
- Reuse already-built constructs/solutions. That is our reason.
- CDK has some obvious downsides, and having an escape hatch of converting CloudFormation can be useful.
- Culture war with (Dev)Ops guys. The real developers, some would say, write every line of CloudFormation by themselves. Anything else is “unworthy of the title developer.”
- The requirement is to produce CloudFormation, but the speed of the development with CDK is unmatched.
I highly discourage having a default solution that converts CDK to CloudFormation. That should be the last escape hatch. CDK brings a lot of benefits and features, and a lot of them cannot be replicated by just converting to CloudFormation. If the “culture war” is the cause of this approach, it would be better to sit down with the opposite side and do an unbiased evaluation of each approach. The end goal is to build a good product with the least resources and not to win culture wars.
We can export to CloudFormation like this:
cdk synth > my_cloudformation.yaml
You do not need anything else. But this approach has several issues:
- CloudFormation has a lot of CDK metadata.
- Logical names have random characters in the postfix.
- Assets are not dropped to any appropriate S3.
In our case, we also want to extend CloudFormation with CloudFormation parameters for the ARN of the SNS topic.
Top comments (0)