An Introduction to AWS CDK

Home Blog An Introduction to AWS CDK
A cloudscape with the AWS CDK logo

Note: this blog post was updated on May 22, 2023. 

In this article we’ll introduce the AWS Cloud Development Kit and explore how it can boost the productivity of your development and infrastructure teams.

Infrastructure-as-Code is fast emerging as a de-facto standard for development organizations.

Having the power to specify your application’s infrastructure in a source-controlled language understood throughout your organization removes a lot of the traditional headaches that defined the line between software engineering and devops engineering. 

As cloud-based technologies have continued to expand, the tech that supports these cloud resources has continued to mature. This gives rise to the latest innovation in AWS resource management, the AWS Cloud Development Kit (CDK)

What is AWS CDK?

The AWS Cloud Development Kit is a framework that can be used by developers to provision and manipulate AWS resources programmatically. 

While many tools like Terraform and CloudFormation exist to give you programmatic access to your application’s resources, many are based in a series of formatted configuration files.

How CloudFormation infrastructure-as-code works.
How CloudFormation infrastructure-as-code works. Source: AWS.

These file configurations can – and often do – provide a wide range of flexibility and functionality. However, these specifications will rarely have the full capability of a traditional programming language. 

The CDK is available in Python and TypeScript as stable builds, and preview builds are available for Java and C#/.NET, allowing your developers to manage infrastructure in the languages that are most comfortable to them.

Comparing AWS CDK to Similar Products

As mentioned above, the AWS CDK is in many ways a layer on top of traditional means of managing infrastructure in code. 

CloudFormation and Terraform rely heavily on markup-based configuration, an approach that allows you to maintain your configurations as data objects. However, these markup languages can often fall short of your organization’s needs, as evidenced by the existence of tools like Serverless Framework, or even AWS’ own Serverless Application Module (SAM)

An example of using declarative infrastructure as code using Terraform.
An example of infrastructure-as-code using Terraform. Source.

While these tools provide power and control, improving the ability of a tech org to maintain and iterate on its own infrastructure, they’re by necessity limited in scope – both Serverless Framework and SAM were built with the needs of a serverless application in mind.

The AWS CDK builds upon this programmatic layer by greatly expanding the number of resources you can manipulate through your code base. Using AWS CDK, you can deploy your entire cloud stack from a small set of programmatic structures, using your engineering department’s strength in development to improve the quality and maintainability of your application’s infrastructure. 

As a first-party AWS product, AWS CDK will also allow you to streamline your costs through consolidation of effort – migrating from an existing infrastructure-as-code platform to an AWS CDK application that provides the same functionality reduces the risk vectors in your application’s deployment, minimizing costs while getting you closer to the AWS resources you are managing.

AWS CDK Example Use Cases

To see the benefits offered by AWS CDK, we’ll look at a couple different use cases. These highlight the role that AWS CDK-based resources would play in a set of hypothetical web apps and microservices.

Use Case 1: A Serverless Utility Function

Utility functions often are the most susceptible to tech debt, as their very existence is intended to solve an internal problem that may not be directly linked to revenue and, accordingly, not assigned sufficient priority by your organization as it works to reach its goals. Generally, in serverless utility functions this problem was compounded by the need to incorporate a third party tool like Serverless Framework to manage your deployment and infrastructure configurations, requiring its own support contacts and having its own esoteric behaviors to be learned and documented. With AWS CDK, you can migrate your existing deployment and configuration scripts into a single code base, built in a common language, using structures and control flows designed as intended by the maintainers of the services you rely upon to run your application.

Use Case 2: A Containerized Application

Applications built using containerized architectures often need to rely upon several tools for deployment and maintenance. They’ll use one set of configurations to construct the containers needed for a particular service, another to deploy the application’s code and related microservices to the appropriate containers, and yet another to tie the disparate containers together into a cohesive whole. The AWS CDK allows you to move several of these indirection layers into code, as artifacts that defines your application rather than markup that describes it. Using the AWS CDK, you can build an infrastructure deployment library that allows you to represent the true interactions between each of your application’s containers, giving you the full power of your programming language of choice to define your application’s infrastructure.

Use Case 3: A Traditional Web Application

Adding AWS CDK to the mix can seem like a complication in a traditional web app environment,  given that often these can be rife with technical debt and one-off integrations that need a fresh set of eyes. There are a few ways in which it provides an immediate benefit, however. Through the AWS CDK, you can construct entire CloudFormation application architectures using only a few lines of code. As your organization no longer needs to create – or maintain – these often problematic configuration files, the overall size of your codebase will be smaller with vastly improved readability. Additionally, by moving this configuration into code, you’re able to better review, verify, and deploy your infrastructure, reducing the cost of spinning up additional supporting resources while also giving your engineers peace of mind when rebuilding your application stack.

Migrating CF Templates to AWS CDK

Moving from CloudFormation Templates to AWS Cloud Development Kit will be the first step for many organizations making the switch. Generally, migrating these templates is handled in one of three ways. The first, and most obvious, is to simply rewrite the template in a script built with CDK. This approach is going to be the most accurate in mirroring the intention of your infrastructure engineers, but will also take the longest and is likely to be the most brittle. A second approach focuses on simply importing your existing Cloud Formation template definitions into your CDK application via the use of provided functionality to simply port the imported file into the final produced template configuration. This approach is by far the quickest way to get your infrastructure running on AWS CDK, but understandably it also does the least to position your developers for success by basically adding a wrapper around your existing template files. A third approach is to use a tool like the AWS CDK CloudFormation Disassembler to translate your CloudFormation templates into CDK-based code. This approach can greatly improve the speed of migrating your resources to AWS CDK, but is not without its own pitfalls.


The AWS Cloud Development Kit is a powerful tool that gives your developers the flexibility and power of maintaining your application’s infrastructure as they would any other element of your application’s code. By translating markup-laden template files into readable code, your organization will be able to more effectively marshall and deploy its cloud resources. The AWS CDK has a broad applicability across a number of different web application architectures, and can be kickstarted using the CloudFormation templates your organization already relies on. Read more about the AWS CDK in the AWS documentation.