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.
AWS CDK introduces not only tooling, wrappers, constructs, and patterns, but also additional elements that allow us to leverage the expressive power of programming languages. Today I’d like to show you such items: aspects that would enable us to do cool stuff, that is very hard to achieve otherwise.
In the previous article, we have overcome two relatively straightforward and expected issues (especially if you have some experience with CloudFormation). Now we have a much bigger problem that we need to face.
Now it’s time to polish our project and face reality, what to do when we observe some problems. Today, we will talk about the prevalent AWS CloudFormation issue surfacing through AWS CDK.
Cloud resources do not exist in isolation, as when it comes to Infrastructure as Code, we deal with infrastructure graph. It means that we need to create relationships between them, and AWS CDK has to support that – so let’s learn how to do it!
Because we use AWS CDK in some areas, we need to adjust our previous approach based, which is based on the experience. Parametrizing stacks is such a place, and today, we will address that difference.
Okay, so after understanding the bootstrap, testing, and why have chosen TypeScript – it’s time to define our first Construct and understand how to use this foundational element in AWS CDK.
Controversial question? Well, maybe – however, I will try to find an objective answer for that critical question in the following blog post.
Now we need to talk about testability! AWS CDK gives us unique selling points and mechanisms related to testing.
Let’s talk about one very important aspect of the CDK structure: bootstrap. Why we need it, and how CDK works under the hood.