Depending on how familiar you are with AWS, you can probably imagine the level of effort required to setup our AWS architecture by hand, let alone describing it consistently so that it deploys to AWS the same way every time. Now consider how we evolve our architecture over time without destabilizing it. At scale, it’s not trivial to do this without some powerful tools. Ideally we would track our AWS architecture one to one with something that can be version controlled.
This is where adopting an infrastructure as code (IaC) approach shines. IaC means we define our AWS infrastructure using a programming language. Foruntately, the AWS Cloud Development Kit (CDK) allows us to do exactly this. We write a program, in our case in TypeScript, and CDK generates and deploys CloudFormation templates on our behalf. CloudFormation is AWS’s underlying low-level infrastructure templating language.
The deliverable of a CDK IaC project is a standalone application. This lets us use any programming language that CDK supports, a development process our team prefers, and a version control system to allow for collaboration and to maintain the quality of the code over time.
These are the basic components of a CDK application that represent ways to create and relate AWS resources. Constructs can be as simple as a DynamoDB table, to representing a Step Functions execution that produces a result.
Composed together, constructs build up the actual unit of deployment of AWS infrastructure, a stack. AWS infrastructure can be logically structured and grouped using stacks. For instance, you may define common infrastructure components like a database and a storage bucket in one base stack that are shared by other stacks, like a stack for a REST API. A CDK application needs to define at least one stack and may contain many stacks.