AWS Cloud Development Kit (CDK) – Big Picture

Big Picture

• Infrastructure as code in TypeScript and Python etc.
• CDK includes
  • Command line interface (CLI) tool
  • Language bindings to CloudFormation resources
  • Construct Library
    • A Construct is a logical grouping of one or more resources
    • Constructs are reusable cloud components

Types of CDK Constructs

• CFN Resources or L1 Construct (or L1, short for “level 1”) or Cfn (short for CloudFormation) resources – low level
• CDK Construct or L2 Construct – high level – provide convenient defaults for CloudFormation resource
• CDK Patterns – higher level abstraction – help you complete common tasks in AWS, often involving multiple kinds of resources

See: https://docs.aws.amazon.com/cdk/latest/guide/constructs.html

Constructs

Constructs are the basic building blocks of AWS CDK apps. A construct represents a “cloud component” and encapsulates everything AWS CloudFormation needs to create the component.

A construct can represent a single resource, such as an Amazon Simple Storage Service (Amazon S3) bucket, or it can represent a higher-level component consisting of multiple AWS resources. Examples of such components include a worker queue with its associated compute capacity, a cron job with monitoring resources and a dashboard, or even an entire app spanning multiple AWS accounts and regions.

L1 Construct (CFN Resource)

There are three different levels of constructs in this library, beginning with low-level constructs, which we call CFN Resources (or L1, short for “level 1”) or Cfn (short for CloudFormation) resources. These constructs directly represent all resources available in AWS CloudFormation.

• CFN Resources are periodically generated from the AWS CloudFormation Resource Specification.
• They are named CfnXyz, where Xyz is name of the resource.
  • For example, CfnBucket represents the AWS::S3::Bucket AWS CloudFormation resource.
• When you use Cfn resources, you must explicitly configure all resource properties, which requires a complete understanding of the details of the underlying AWS CloudFormation resource model.

L2 Construct (CDK Construct)

The next level of constructs, L2, also represent AWS resources, but with a higher-level, intent-based API. They provide similar functionality, but provide the defaults, boilerplate, and glue logic you’d be writing yourself with a CFN Resource construct. AWS constructs offer convenient defaults and reduce the need to know all the details about the AWS resources they represent, while providing convenience methods that make it simpler to work with the resource. For example, the s3.Bucket class represents an Amazon S3 bucket with additional properties and methods, such as bucket.addLifeCycleRule(), which adds a lifecycle rule to the bucket.

Patterns

Finally, the AWS Construct Library includes even higher-level constructs, which we call patterns. These constructs are designed to help you complete common tasks in AWS, often involving multiple kinds of resources. For example, the aws-ecs-patterns.ApplicationLoadBalancedFargateService construct represents an architecture that includes an AWS Fargate container cluster employing an Application Load Balancer (ALB). The aws-apigateway.LambdaRestApi construct represents an Amazon API Gateway API that’s backed by an AWS Lambda function.

Composition

Composition is the key pattern for defining higher-level abstractions through constructs. A high-level construct can be composed from any number of lower-level constructs, and in turn, those could be composed from even lower-level constructs, which eventually are composed from AWS resources. From a bottom-up perspective, you use constructs to organize the individual AWS resources you want to deploy using whatever abstractions are convenient for your purpose, with as many layers as you need.

Composition lets you define reusable components and share them like any other code. For example, a team can define a construct that implements the company’s best practice for a DynamoDB table with backup, global replication, auto-scaling, and monitoring, and share it with other teams in their organization, or publicly. Teams can now use this construct as they would any other library package in their preferred programming language to define their tables and comply with their team’s best practices. When the library is updated, developers will get access to the new version’s bug fixes and improvements through the workflows they already have for their other types of code.

Also see

• CDK Construct Catalog – a community project and is not officially supported by AWS
• aws-samples/aws-cdk-examples – official list of CDK example code
• AWS CDK Patterns – An Opensource Collection of Serverless Architecture Patterns
  • cdk-patterns – ​github repo for ckdpatterns.co
  • cdk-patterns/cli – CLI tool for cdkpatterns.com to make it as simple as one command to download and learn a new pattern. 

CDK App, Stack, Environment

• An App can contain one of more stacks
• The unit of deployment in the AWS CDK is called a stack.
  • All AWS resources defined within the scope of a stack, either directly or indirectly, are provisioned as a single unit.
• Each Stack instance in your AWS CDK app is explicitly or implicitly associated with an environment (env)

Docs:

• https://docs.aws.amazon.com/cdk/latest/guide/apps.html
• https://docs.aws.amazon.com/cdk/latest/guide/stacks.html
• https://docs.aws.amazon.com/cdk/latest/guide/environments.html

CDK Workflow

Init

Project (app) is created using cli:

$ cdk init <template> -l <language>

Available templates:
* app: Template for a CDK Application
   └─ cdk init app --language=[csharp|fsharp|go|java|javascript|python|typescript]
* lib: Template for a CDK Construct Library
   └─ cdk init lib --language=typescript
* sample-app: Example CDK Application with some constructs
   └─ cdk init sample-app --language=[csharp|fsharp|java|javascript|python|typescript]

Bootstrap

Create needed AWS resources for CDK environment:

$ cdk bootstrap

Synth

Generate CloudFormation templates from code

$ cdk synth

Deploy

Templates are launched by CloudFormation or CDK stacks are deployed:

$ cdk deploy

# using a specific profile
$ cdk deploy --profile PROFILE_NAME

# deploy a specific stack
$ cdk deploy STACK_NAME

# deploy multiple stacks
$ cdk deploy STACK_1 STACK_2

# deploy all stackes in the app
$ cdk deploy "*"

List the stacks in the CDK app:

$ cdk list

Delete the stack:

$ cdk destroy

Compare local and deployed stack:

$ cdk diff

Check for problem:

$ cdk doctor