AWS CloudFormation vs AWS Cloud Development Kit(CDK)

There are a few areas that may provide benefits:

1. It is easier to build and use interfaces at a suitable level for a use case, rather than being forced into low-level details for pretty much everything with CloudFormation.
2. Better default tooling. AWS CDK has a command-line tool that makes it rather easy to deploy, update, check for changes and delete Cloud infrastructure stacks. The default tooling using either AWS CLI or AWS Tools for PowerShell frankly sucks in comparison.
3. Better language tooling. There are more and better tools to support writing (complex) things in programming languages, than YAML or JSON.
4. Better organizational capabilities in AWS CDK, what to put where and how and when to parameterise the infrastructure.

There are also drawbacks that come with AWS CDK:

1. Additional complexity. While CloudFormation YAML/JSON sucks to build abstractions, it has the benefit that it is more clear what infrastructure will be generated at a micro-level. You are a bit more at risk of shooting yourself in the foot with bad code in AWS CDK.
2. Dependency on Node.js, and NPM. Regardless of which programming language you use, you will need to have a Node.js runtime installed from NPM. This is for the command-line tool.
3. Leaky abstractions. AWS CDK uses AWS CloudFormation under the hood, and in some areas that show through. This means you need to understand both AWS CDK and some CloudFormation for some scenarios.

You can essentially use the AWS CDK command-line tool to make a better workflow and take advantage of benefits 2 and 4 and still write your infrastructure with CloudFormation only, or you can go all-in on programming language code, or somewhere in between. We will explore different options as part of the migration efforts we will look at.