The AWS CDK Overview

Welcome — in this lesson we’ll cover the AWS Cloud Development Kit (CDK), how it integrates with AWS CloudFormation, typical workflows, examples, and best practices for using CDK to manage infrastructure as code. The CDK (Cloud Development Kit) lets you define AWS infrastructure using familiar general-purpose programming languages (TypeScript, Python, Java, Go, etc.). Instead of hand-writing CloudFormation templates in YAML/JSON, you author code that the CDK synthesizes into CloudFormation templates. That gives you the benefits of traditional programming—flow control, loops, conditional logic, abstractions, testing, and reusable components—while still relying on CloudFormation to perform the actual provisioning. What CDK provides:

Higher-level constructs that encapsulate common configurations and best practices.
A synthesis step (cdk synth) that emits CloudFormation templates.
A deploy step (cdk deploy) that leverages CloudFormation to create and update resources.
Tooling to bootstrap environments and integrate into CI/CD pipelines.

CDK is ideal when you want the safety and stability of CloudFormation but prefer to author infrastructure in code. Use it to standardize patterns, run unit tests against infrastructure, and reuse components across accounts and environments.

When we say “infrastructure as code”, we mean a reproducible blueprint for your AWS resources. You write the blueprint (CDK code), the CDK synthesizes a CloudFormation template, and CloudFormation provisions the resources—avoiding manual steps and improving repeatability. Typical high-level flow:

Author CDK app using constructs and stacks.
Run cdk synth to generate CloudFormation templates.
Run cdk deploy to create/update stacks via CloudFormation.

A diagram of the AWS CDK workflow: a CDK app (with constructs written in multiple languages) runs cdk synth to produce CloudFormation templates, which are then deployed to AWS CloudFormation as stacks via cdk deploy.

Why use the CDK?

Declarative infrastructure expressed using general-purpose languages.
Component reusability through constructs.
Access to the AWS Construct Library (L2/L3 constructs) that encapsulate best practices.
Automated synthesis and straightforward pipeline integration.
Environment parameterization (dev/staging/prod) without duplicating definitions.

CDK constructs follow a hierarchy that improves reuse and developer ergonomics:

Construct Level	Description	Use case
Level 1 (L1)	Low-level constructs that map 1:1 to CloudFormation resources	When you need exact CloudFormation resource properties
Level 2 (L2)	Rich, opinionated constructs with sensible defaults and idiomatic APIs	Day-to-day resource creation with safer defaults
Level 3 (L3)	High-level patterns and architectural abstractions that configure multiple resources together	Provision complete patterns (e.g., queue + topic fanout)

A slide titled "AWS CDK – Hierarchy of Constructs" showing a CDK app diagram with stacks containing Construct L1, L2, and L3. To the right it maps L1 to raw CloudFormation resources, L2 to CDK wrappers with sensible defaults, and L3 to high-level pattern abstractions.

Core CDK CLI commands

cdk init — scaffold a new project
cdk bootstrap — prepare an AWS environment with resources CDK needs (for example, an S3 bucket for asset storage)
cdk synth — synthesize the CloudFormation template(s)
cdk deploy — deploy the synthesized template(s) via CloudFormation
cdk destroy — remove stacks created by CDK

Use the table below as a quick reference:

Command	Purpose
`cdk init`	Create a new CDK project scaffold
`cdk bootstrap`	Set up account/region with required resources (e.g., S3 bucket for assets)
`cdk synth`	Emit CloudFormation templates from your CDK app
`cdk deploy`	Deploy synthesized templates using CloudFormation
`cdk destroy`	Tear down stacks created by CDK

These commands accept flags and options for environment, profile, context, and more. Integrate them into CI/CD flows and automation scripts.

A presentation slide titled "Features" showing five numbered cards with colorful circular icons and labels: 01 Declarative approach, 02 Component reusability, 03 AWS Construct Library, 04 Automated synthesis, and 05 Environment agnosticism. The slide has a clean, minimal layout with a KodeKloud copyright in the corner.

CDK and CI/CD In CI/CD, treat CDK code like application code: store it in Git, run unit tests and linters, synthesize templates, and deploy only from trusted pipelines. Typical pipeline flow:

Source control (Git)
Build stage: run unit tests, linters, cdk synth
Deploy stage: cdk deploy (backed by CloudFormation) or orchestration by services such as AWS CodePipeline

Example services: CodeBuild executes tests and CDK commands; CodePipeline orchestrates stages and triggers CloudFormation deployments.

A diagram of a CDK pipeline where a developer pushes code to AWS CodeCommit, which goes through AWS CodeBuild and AWS CloudFormation. The CloudFormation stack provisions resources like S3, EC2, VPC, and RDS.

Practical example — Python CDK stack that creates an S3 bucket This concise example demonstrates how CDK lets you create an S3 bucket with common options. The CDK API is idiomatic and readable.

from aws_cdk import (
    Stack,
    aws_s3 as s3,
    RemovalPolicy,
)
from constructs import Construct


class CdkS3BucketStack(Stack):
    def __init__(self, scope: Construct, id: str, **kwargs) -> None:
        super().__init__(scope, id, **kwargs)

        bucket = s3.Bucket(
            self,
            "MyCdkBucket",
            versioned=True,  # Enable versioning
            removal_policy=RemovalPolicy.DESTROY,  # Delete bucket when stack is deleted
            public_read_access=False,  # Private by default
        )

        # Expose the bucket name for use by other stacks or tests
        self.bucket_name = bucket.bucket_name

Setting RemovalPolicy.DESTROY instructs CloudFormation to delete the S3 bucket when the stack is destroyed. S3 bucket deletion will fail if the bucket still contains objects. If you need automatic object removal during stack deletion, enable auto-delete object options on the construct or use a custom resource to empty the bucket. Use destructive policies with caution—especially in production.

Best practices for CDK projects

Build reusable constructs for common infrastructure components to standardize patterns.
Parameterize configuration (context, parameters, environment variables) rather than hardcoding values.
Enable CloudFormation stack policies and safeguards for production stacks.
Use environment-level bootstrapping (CDK toolkit) for multi-account/multi-region deployments.
Test infrastructure: include unit tests, integration tests, and linters in CI/CD.
Review synthesized templates (cdk synth) and version them if you need to track actual CloudFormation templates.

A slide titled "AWS CDK – Best Practices" listing recommendations such as using CDK constructs for reusability, parameterizing instead of hardcoding, enabling CloudFormation stack policies, using the CDK toolkit for multi-account deployments, and testing infrastructure before deployment. The slide includes blue circular icons next to each bullet and a copyright note from KodeKloud.

Demo and learning path A useful hands-on flow to practice:

cdk init — create a new project in your preferred language.
Create stacks and constructs that model your infrastructure.
cdk synth — inspect the generated CloudFormation templates.
cdk deploy — deploy to a sandbox account.
Integrate these steps into a CI/CD pipeline (CodeBuild, CodePipeline, GitHub Actions, etc.).

Links and references

AWS CDK official docs: https://docs.aws.amazon.com/cdk/
AWS CloudFormation docs: https://docs.aws.amazon.com/cloudformation/
AWS Construct Library: https://docs.aws.amazon.com/cdk/api/latest/docs/aws-construct-library.html
KodeKloud CloudFormation course: https://learn.kodekloud.com/user/courses/aws-cloud-formation
Learn more about S3: https://learn.kodekloud.com/user/courses/amazon-simple-storage-service
CodePipeline overview: https://learn.kodekloud.com/user/courses/aws-codepipeline-ci-cd-pipeline

Thanks for reading this lesson/article.

Introduction

Domain 1 - SDLC Automation

Domain 2 - Configuration Management and IaC

Domain 3 - Resilient Cloud Solutions

Domain 4 - Monitoring and Logging

Domain 5 - Incident and Event Response

Domain 6 - Security and Compliance

The AWS CDK Overview

Watch Video