AWS CDK Considered Harmful

Hiya,

Reasons to avoid the AWS CDK (and CloudFormation of course) for your IaC needs:

It's AWS only. If you want to go and automate your GitHub org, Tailscale routers, DataDog, StrongDM, Kubernetes (CDK8s not included), or any other API that you want to interact with, you're SOL and need to go with another tool. That makes it a non-starter for many teams, especially at organizations that have anything that lives outside of AWS.

The split of the community due to the "Bring your own Language" concept affects everyone, because you lose interoperability. One of the best things about the Terraform and OpenTofu ecosystem is the extensive open source module libraries. Pulumi and CDK both suffer from having their module libraries being split between many different languages.

Some people mention Custom Resources as a way to avoid issue #1 listed above. I personally don't think Custom Resources is a route I'd want to go down as it sounds like a high level of investment. But if you're a 100% AWS org and you keep almost everything in the ecosystem, then I understand the allure since your automation needs outside of AWS are likely very low.

You can somewhat work around issue #2 with jsii. I know Pulumi has a similar mechanism for cross-language module / package usage. From afar, I've always seen that as a can of worms that I wouldn't want to touch. Transpiled code always seems nice but sometimes requires you to debug two (or even more) different languages. I will say we don’t have direct experience with this, though.

Other options in order of priority:

• Terraform/OpenTofu (what we recommend)

• Pulumi

• Coding directly against an SDK (if you want to make your infrastructure changes require developer effort)

Happy avoiding-CDK-ing,

Matt

PS Want more Terraform? Check out our post on terraform-null-label from last year.