7.3 Infrastructure as Code with AWS CDK

7.3 Infrastructure as Code with AWS CDK

CloudOps Blueprint Focus: As cloud operations modernize, defining infrastructure using general-purpose programming languages has become standard enterprise practice. On the AWS Certified CloudOps Engineer – Associate (SOA-C03) exam, you must understand the relationship between the AWS Cloud Development Kit (CDK) and CloudFormation, navigate the construct hierarchy (L1, L2, L3), execute core CDK CLI commands, and manage the bootstrapping architecture required for deployment assets.

The AWS CDK Architecture & CloudFormation Relationship

The AWS Cloud Development Kit (CDK) is an open-source software development framework that allows engineers to model and provision cloud application infrastructure using familiar, object-oriented programming languages including TypeScript, JavaScript, Python, Java, C#, and Go.

Using general-purpose programming languages provides significant operational advantages over static JSON/YAML templates:

• Code Reuse & Abstraction: Create reusable classes, loops, conditionals, and object-oriented inheritance models.
• Modern Tooling: Leverage native package managers (npm, pip, Maven, NuGet), integrated linters, type checkers, and unit testing frameworks (Jest, pytest).
• Integrated Logic: Construct dynamic resource configurations without awkward JSON/YAML macros.

The Operational Reality: CDK Synthesizes CloudFormation

A critical concept for CloudOps engineers is that AWS CDK does not make direct AWS API calls to provision or manage infrastructure resources. Instead, CDK is a compiler and synthesis engine:

1. The engineer executes the CDK CLI (cdk synth or cdk deploy).
2. The CDK application executes and compiles the construct code tree into standard CloudFormation templates and asset bundles in the local cdk.out directory.
3. The CDK CLI submits these synthesized templates to AWS CloudFormation.
4. AWS CloudFormation executes the deployment, managing resource provisioning, state tracking, dependency graphs, and automated rollbacks.

CloudFormation remains the ultimate deployment engine and system of record for all CDK applications.

---

The Core CDK Hierarchy: App, Stack & Environment

A CDK application is structured as an inverted construct tree with three fundamental structural tiers:

• App: The root construct container of any CDK application. The App manages one or more Stack constructs and defines the overall application boundary.
• Stack: The unit of deployment in AWS CDK. Every CDK Stack maps 1:1 to an underlying AWS CloudFormation stack. All resources declared inside a CDK Stack are synthesized into a single CloudFormation template. Stacks can reference resources from other stacks; CDK automatically establishes cross-stack references using CloudFormation exports (Export: Name) and imports (Fn::ImportValue).
• Environment: Configured on each Stack to designate the target AWS Account ID and AWS Region (env: { account: '123456789012', region: 'us-east-1' }). Stacks without an explicit environment are environment-agnostic (synthesizing templates that utilize pseudo parameters like AWS::AccountId and AWS::Region), while environment-specific stacks can query live VPCs, AMIs, and hosted zones at synthesis time via context providers.

---

The Three-Tier Construct Levels Hierarchy

In AWS CDK, everything is a Construct. Constructs represent cloud components and are categorized into three levels of abstraction:

L2 Constructs in Action: Granular IAM & Defaults

L2 constructs eliminate hundreds of lines of boilerplate. For example, instantiating new ec2.Vpc(this, 'AppVPC') automatically creates a multi-AZ VPC, public and private subnets, internet gateways, NAT gateways, and route tables with optimal CIDR allocations. Furthermore, calling myBucket.grantRead(myRole) automatically generates the least-privilege IAM policy statement and attaches it to the role, avoiding manual IAM JSON authoring.

---

CDK CLI Lifecycle & Workflow Commands

The CDK Command Line Interface (CLI) drives the development and deployment lifecycle:

• cdk init: Initializes a new CDK project from a template in the specified language (e.g., cdk init app --language typescript).
• cdk synth: Executes the application and synthesizes CloudFormation templates into the cdk.out directory. Validates template syntax and construct logic locally without interacting with live AWS resources.
• cdk diff: Compares the local synthesized template against the currently deployed CloudFormation stack in AWS. It displays a color-coded delta showing resource additions, modifications, and deletions, and explicitly highlights security-sensitive changes (such as altered IAM statements or broadened security group ingress rules).
• cdk deploy: Synthesizes the template, packages and uploads deployment assets, and initiates the CloudFormation stack deployment. By default, it prompts for interactive approval when security-sensitive changes are detected (can be bypassed in CI/CD using --require-approval never).
• cdk destroy: Deletes the deployed CloudFormation stack and tears down managed resources.

---

CDK Bootstrapping Architecture: CDKToolkit & Assets

CDK applications frequently bundle external assets, such as AWS Lambda function code directories, Docker container build contexts, or CloudFormation templates exceeding the 50 KB direct upload limit.

To manage these assets, the target AWS account and Region must be initialized using the cdk bootstrap command (cdk bootstrap aws://123456789012/us-east-1).

Resources Provisioned by the CDKToolkit Bootstrap Stack

Bootstrapping provisions a dedicated CloudFormation stack named CDKToolkit in the target environment, creating:

1. Amazon S3 Bucket: Stores synthesized CloudFormation templates and compressed Lambda function zip archives.
2. Amazon ECR Repositories: Stores Docker container images built by the CDK CLI for ECS or Lambda container deployments.
3. IAM Roles: Creates dedicated deployment and publishing roles (cdk-*-deploy-role, cdk-*-file-publishing-role, cdk-*-image-publishing-role, cdk-*-lookup-role) with defined trust policies, enabling secure cross-account deployments within AWS Organizations.

Bootstrapping must be executed once per target account/Region before deploying CDK applications that utilize assets or large templates.