Automating Infrastructure Creation

The Struggles with Adopting AWS: Part II

Automating infrastructure or infrastructure as code is a critical part of creating the operation process. It provides reproducibility, plus it is less error-prone and version controllable.

There are many tools for solving the infrastructure-as-code problem in AWS. These include AWS CloudFormation and HashiCorp’s Terraform. But the Cloud Development Kit (CDK) is the newest one, preferred by AWS, and the one we are teaching in our Customized Training.

Intro to Cloud Development Kit

The CDK sits atop AWS CloudFormation and generates cloud formation templates in JSON or YAML. CDK can utilize a number of programming languages, so you can select the one you want, but the primary one is TypeScript rather than Java, JavaScript, C# Go, or Python.

We use automation and CDK to save time and prevent errors. The alternative method—doing it manually—is quite prone to errors. If you’re using the CDK, it takes what you wrote and gets the running resources up to the state in which you want them to be. So it takes care of all those changeset details for you.

Other Options—and Drawbacks

You also could do it by using shell scripts in the CLI, but then you are making changesets for every time you want to make a change. Another alternative would be to use cloud formation directly, and those templates are written in JSON or YAML, and complex CloudFormation templates can be very difficult to write and maintain.

There are some popular third-party components such as Terraform, but it’s not sanctioned or developed by the AWS teams. That means you will likely be lagging features behind in what is provided by AWS versus what the third-party tooling provides.

Another advantage to using CDK is that it has best practices built into it, meaning your developers don’t need to be as familiar. Using the CDK, you can initiate a CDK application from a project template, then you can define the stacks. Inside a stack, you can use the CDK constructs (components) to define the AWS resources you want it to generate when the stack is deployed.

There are 3 layers of CDK constructs/components:

  • L1 – Direct translation between TypeScript objects and CloudFormation objects.
  • L2 – Curated constructs, which have best practices built-in (and are what you should be using).
  • L3 – Patterns. These aggregate L2 constructs level two to create more complex sets of orchestration between AWS resources.

CDK provides a unit testing framework to improve the quality of your infrastructure automation. It’s not obvious what you are testing. The testing framework doesn’t actually validate the resources are running based on the CDK application but that the CloudFormation templates get generated correctly.

Examples of what you might automate with the CDK could include:

  • CI/CD pipelines that may include a CodePipeline, CodeCommit, CodeBuild and CodeDeploy.
  • Containerized production environment with Green/Blue deploy using CodeDeploy, Elastic Container Repository (ECR) and Elastic Container Service (ECS) or Elastic Kubernetes Service (EKS).
  • Serverless application using static websites, Lambdas, API gateways and DynamoDB.

The biggest drawback of CDK relative to, say, Terraform, is that if you ever decide to move away from AWS then you will have to start all over again. Whereas, with Terraform, if you went to Azure or Google Cloud, you should be able to make a few changes and then stand up the same type of infrastructure.

If you know that you want to stick with AWS technologies, cloud formation or the CDK is a great solution.

To get started today, reach us at