AWS CDK Business Infrastructure as Code

AWS CDK? Why not Terraform?

In many cases, the community treats Terraform as a sane default when it comes to the infrastructure as code. I can’t entirely agree with that statement, mainly if this is wrongly motivated. Today, I would like to present the unique selling points that show when using AWS CDK is a better-suited tool for the job.

Sigh. If I had a penny every single time, I proposed AWS CloudFormation or AWS CDK for the infrastructure as code solution, and I received pushback in the form of a question: why not Terraform instead? I’d have a significant amount of metal scraps in my wallet.

Good arguments rarely support this pushback, and it’s wrong on so many levels, so please allow me to tackle this bit by bit.

Origin of the statement “Terraform is a sensible default”

This statement predates the example I want to show, but I will still use it as an example because it clearly shows how far it went.

Excerpt from the 20th Thoughtworks Technology Radar (April 2019) provides a phrase: "We find Terraform a sensible default".
Excerpt from the 20th Thoughtworks Technology Radar (April 2019) provides a phrase: “We find Terraform a sensible default”.

Above, you can see that handwritten AWS CloudFormation is marked as a HOLD technique. For those of you who are not familiar with the categories – Thoughtworks is classifying specific solutions, tools, and techniques with labels ADOPTTRIALASSES, and HOLD. As you’ve probably deduced, the last one says to proceed with caution when using it.

Being brutally honest, inside this paragraph, there is plenty of arguments against AWS CloudFormation, and they have a point there. However, that reflects only more aware voices of the community.

Here is the problem with this reasoning in a broader context: when you are choosing infrastructure as code solution, many experts say like a mantra that you need a tool that is an OSS one because you will be increasing your vendor lock-in without tat.

However, it’s hard to be mad on Thoughtworks as they did not say that. Yet, their report reflects just a fraction of the community, which stopped at the first available solution that provides an alternative for the least essential problems: DSL syntax (referred to as shortfalls of CloudFormation) and imaginative danger of the vendor lock-in.

When I am starting a discussion with the claim about the imaginative danger of vendor lock-in, many people actually pushback again and begin to talk about why it’s so wrong to use a tool for infrastructure as code provided by your cloud provider.

Well, this motivation it’s a fallacy, so allow me to explain why.

Leaky abstractions are the wrong answer to a vendor lock-in problem

Let me explain what kinds of lock-in we face. For that, I will use a fantastic essay from Gregor HohpeDon’t get locked up into avoiding lock-in.

He defines a great list of various shades of lock-in:

  • Vendor Lock-in.
  • Product Lock-in.
  • Version lock-in.
  • Architecture lock-in.
  • Platform lock-in.
  • Skills lock-in.
  • Legal lock-in.
  • Mental Lock-in.

So it’s not a binary choice, it’s more like risk management and cost-benefit analysis. Additionally, he puts very elegantly that pursuing a crusade against one type of lock-in may create another one:

New Lock-ins: Avoiding one lock-in often comes at the expense of another one. For example, you may opt to avoid AWS CloudFormation and instead use Hashicorp’s Terraform or Pulumi, which both support multiple cloud providers. However, now you are locked into another product from an additional vendor and need to figure out whether that’s OK for you.

Gregor Hohpe about new lock-ins that arise from obsessively removing another one.

So why I think Terraform is a leaky abstraction in such a case? All of you who wrote a little bit of Terraform know that it does not provide an abstraction layer for the AWSAzure, or Google Cloud. It does that deliberately, as you should embrace all aspects when using cloud – not extract a common denominator from the services delivered by the cloud provider. And the author of this essay elegantly points this out as well: 

When calculating the cost of avoiding lock-in, an architect should make a quick run down this list to avoid blind spots. Also, be aware that attempts at avoiding lock-in can be leaky, very much like leaky abstractions. For example, Terraform is a fine tool, but its scripts use many vendor-specific constructs. Implementation details thus “leak” through, rendering the switching cost from one cloud to another decidedly non-zero.

Gregor Hohpe about leaky abstractions and why in the context of avoiding platform/vendor lock-in, it may be a wrong choice.

Unique Selling Points of AWS CDK

Okay, so as we left behind the misguided arguments about Terraform, let’s talk about places when you should consider AWS CDK as it will be the right solution:

  • It provides a very gentle way of introducing topics of infrastructure as code to the developers. This way is more natural for the developers and exposes a natural bridge to them, so it will be easier to encourage them into more elements of DevOps culture responsibilities.
  • It removes shortfalls of AWS CloudFormation related to syntax, reusability, and modularity. Better flexibility in the experienced and aware hands gives more power and expressiveness, which is a great asset.
  • You still want to use AWS CloudFormation because you like certain guarantees not provided by the other tools (e.g., safe rollback).
  • With the rise of Serverless applications and architectures, this will be a great alternative to the Serverless Framework and the others.
  • It looks like AWS wants to invest more heavily in it, as it is creating more bridges, like the one for Kubernetes (cdk8s).

When not to use AWS CDK?

I think that is often the most missed section is such kind of articles. Many of us, engineers, are guilty of drinking the kool-aid and focusing on just one side of the problem. It’s a mistake because tools are rarely a solution that gives terrific ROI.

Side note: If you are interested in this topic, I strongly encourage you to read an essay from Fred P. Brooks titled No Silver Bullet – Essence and Accident in Software Engineering about accidental and essential complexity, and hopefully, you will understand my point about pointless hope put into many tools.

That’s why I have prepared a list (which is not exhaustive, I would love to learn more about your misguided approach to AWS CDK and lessons learned from it) that may be a useful heuristic when to avoid this tool:

  • It’s not a great tool if your environment is focused on multi-cloud, or you heavily depend on multiple providers (e.g., some parts of the infrastructure are on the AWS, but domains and CDN are somewhere else). In this case, Terraform is a more appropriate tool.
  • It’s hard to divide your applications and company structure into independent teams that should manage their applications end-to-end. This may severely complicate the whole approach to embracing AWS CDK in a most-effective way.


I hope this article will help you to not copy this misguided argumentation about Terraform. If that will convert from that path at least person, I will be more than happy. There will be fewer sighs and metal scraps in my pockets. 😂

By Wojciech Gawroński

Principal Cloud Architect at Pattern Match. Infrastructure as Code, DevOps culture and AWS aficionado. Functional Programming wrangler (Erlang/Elixir).


This site uses Akismet to reduce spam. Learn how your comment data is processed.