- Published on
AWS CDK Glossary - Part I
- Name
- Roman Naumenko
AWS CDK is a large software project. When AWS released CDK, they introduced many new terms and definitions at the edge of software development, infrastructure configuration management, and software abstractions. What's the meaning of those terms from a software development perspective?
I created a table with core AWS CDK terminology, a brief software-related explanation of each term, and further links to look up relevant docs or code.
Term | What it means |
|---|---|
AWS CDK | AWS CDK is a programming framework for coding special "infrastructure" applications and libraries. CDK applications provision infrastructure through AWS CloudFormation. In addition to Cloudformation, It supports some other tools: K8S and Terraform. Links: How AWS defines CDK |
CDK construct | AWS is using the fancy word "construct" to describe NPM modules included in the CDK. The modules encapsulate information for CloudFormation to create and manage a resource of AWS service. Modules can provide defaults and glue logic to easily manage Cloudformaiton resources. The others modules are directly generated from Cloudformation specs. |
L1 Construct | These are "low-level" construct modules that provide classes to represent resources directly from CloudFormation. L1 Resources are periodically generated from the AWS CloudFormation Resource Specification. They are named as Install respective npm package, for example, CfnBucket requires @aws-cdk/aws-s3 npm package to see the L1 classes source. |
| These constructs are the same as L1 Construct |
L2 or "Curated" Constructs | CDK modules that provide classes to provision AWS resources with defaults, boilerplate code, glue logic, and convenience methods. The source of L2 constructs contains a lot! For example, class Bucket contains 2500 lines of TypeScript code. Plus other resources: Lambda functions, etc. |
L3 or "Pattern" | L3 constructs (AWS calls them "patterns") is CDK module with classes to provision or orchestrate multiple AWS resources for a useful service or abstraction. Example: @aws-cdk/aws-s3-deployment construct: with a few parameters, it can upload files from local disk to S3. These modules often create Lambda functions to perform specific actions. A whole bunch of constructs: AWS Solution Constructs |
AWS Construct | This is |
AWS Solutions | AWS wrote CDK modules for various architectures vetted by AWS. AWS published these Solutions under "AWS Solutions Library" as AWS Solutions Constructs. Those are L3 "pattern" constructs. Links: Check patterns source code for solution constructs in Github. |
CDK Toolkit | This is simply a CLI (written in TypeScript). It provides convenient options for generating CloudFormation templates from CDK code, deploying stacks, initializing new CDK applications, etc Links: CDK CLI |
CDK App | CDK Apps are written in TypeScript or other languages supported by CDK. Each app defines one or more CDK Stacks. |
CDK Stack | It is equivalent to the CloudFormation stack, however, it is designed as a class in a programming language. Stack contains CDK Constructs. The Stack class has an endless list of props, parameters and methods - check it out on docs page for Stack class |
CDK framework using novel terminology. As you can see, the terms are often used interchangeably (CDK Toolkit = CDK CLI). The best approach to grasp these terms is to consider CDK as a software project. It provides classes and functions to generate Cloudformation templates that can deploy and manage anything on AWS: from a single AWS resource to sophisticated applications.
AWS builds CDK as a hierarchy of abstractions to make this happen. Low-level CDK classes provide direct access to all config options in Cloudformation resources. Then higher-level CDK classes encapsulate patterns of defaults for Cloudformation services. Of course, developers do not stop there: CDK "architecture" classes can create services containing a dozen AWS resources.
The principles remain the same:
- low-level, repetitive details get hidden
- abstractions provide new valuable properties
- development productivity increases
The practical way to get familiar and keep up with CDK jargon is to treat it as a software project. I highly recommend checking examples in the documentation or source code concerning specific terms. That's where AWS keeps the definitions pretty consistent, compared to marketing and landing pages.
Here are a few rhymes to remember core concepts:
- L1 construct - pull Cloudformaiton levers to act
- L2 construct - get Cloudformation more abstract
- L3 construct - best Cloudformation bang for the code buck
- CDK Stack - Cloudformation stack into a class unpacked
In the second part of this post, I will dig into the definitions of classes types and other CDK programmatic internals.