AWS CDK Constructs: English Vocabulary for Infrastructure as Code

AWS CDK has its own vocabulary — and it’s not just technical jargon. The words engineers use when discussing CDK reflect specific concepts about abstraction levels, resource ownership, and deployment boundaries. If you’re working on an AWS-heavy team, you’ll hear these terms in code reviews, architecture discussions, and Slack threads every day. This post teaches you how to use them naturally.

The Three Levels of Constructs

The most important conceptual vocabulary in CDK is the construct hierarchy. Engineers talk about L1, L2, and L3 constructs constantly.

L1 Construct (CloudFormation Resource)

An L1 construct is a direct, low-level representation of a CloudFormation resource. The name comes from “Level 1.” L1 constructs give you complete control but require you to specify every property explicitly.

“We dropped down to an L1 construct for the Lambda permission because the L2 didn’t expose the FunctionUrlAuthType property yet.”

The phrase drop down to (or fall back to) an L1 is very natural — it implies you’re moving to a lower abstraction level by necessity.

L2 Construct (Intent-Driven)

An L2 construct is an opinionated, higher-level abstraction that encapsulates sensible defaults and exposes a cleaner API. Most CDK engineers work at this level day-to-day.

“The aws_s3.Bucket L2 construct automatically sets up server-side encryption by default. You have to explicitly opt out if you don’t want it.”

Key phrases: sets sane defaults, opinionated, intent-driven, encapsulates the boilerplate.

L3 Construct (Pattern)

An L3 construct — also called a pattern — bundles multiple resources into a reusable architecture. These often come from aws-solutions-constructs or are written in-house.

“We built an L3 construct that provisions an API Gateway, a Lambda function, and a DynamoDB table together — with all the IAM wiring handled internally.”

Escape Hatch

An escape hatch is a CDK mechanism that lets you access and modify the underlying CloudFormation resource when the L2 or L3 abstraction doesn’t expose what you need.

“We had to use an escape hatch to set a raw CloudFormation property that the L2 construct didn’t surface. It’s not ideal, but it works.”

The term comes from the idea of “escaping” the abstraction. In code reviews you’ll hear: “Can we avoid the escape hatch here? There might be a cleaner way using the L2 API.”

Stack and App

Stack

A stack is the unit of deployment in CDK — it maps directly to a CloudFormation stack. Engineers talk about stacks as containers for related resources.

“We split the VPC into its own stack so other stacks can reference it without redeploying networking every time.”

Common verbs: deploy a stack, synthesize a stack, destroy a stack, reference across stacks.

App

The app is the root of a CDK application — the entry point that contains all stacks. Engineers rarely discuss the app itself in detail, but the phrase matters.

“The app instantiates three stacks: one for networking, one for the API layer, and one for the data tier.”

Synthesis

Synthesis (verb: synthesize) is the process of converting your CDK code into CloudFormation templates. It happens before deployment.

“Synthesis failed because we had a circular dependency between stacks. We need to restructure which stack owns the shared security group.”

You’ll also hear synth as shorthand: “Run cdk synth and check what CloudFormation template it produces.”

Bootstrapping

Bootstrapping is a one-time setup process that prepares an AWS account and region for CDK deployments — it creates the S3 bucket and IAM roles CDK needs to operate.

“The pipeline failed in the new account because nobody ran cdk bootstrap yet. The staging environment wasn’t bootstrapped.”

A common mistake is confusing bootstrapping (account setup) with deployment (running cdk deploy). In conversations: “Is that account bootstrapped?” is a standard diagnostic question.

Asset Bundling

Asset bundling refers to the process of packaging application code — Lambda functions, Docker images — as part of the CDK build. CDK can bundle assets locally or in Docker.

“Asset bundling is slowing down our CI pipeline. We’re looking at using bundling.image with a custom Docker image to cache the node_modules layer.”

Cross-Stack References

A cross-stack reference is when one CDK stack exports a value (like a VPC ID or an ARN) that another stack imports and uses.

“Be careful with cross-stack references — if you rename an export, CloudFormation will refuse to deploy until you update all stacks that import it.”

The gotcha phrase here: “CloudFormation will refuse to deploy” — this is natural and direct, not “CloudFormation will not be able to deploy.”

CDK Context

Context in CDK is a key-value store for configuration values — things like account IDs, environment names, or feature flags. It is stored in cdk.context.json.

“We use CDK context to inject the environment name at synth time. The same stack code deploys to dev, staging, and prod with different context values.”

Code Review Phrases for IaC

Requesting a lower abstraction level:

• “This could be an L2 construct — do we really need to configure every CloudFormation property manually?”

Flagging an escape hatch:

• “We’re using an escape hatch here. Let’s add a comment explaining why the L2 API isn’t sufficient.”

Discussing cross-stack coupling:

• “I’d rather not create a cross-stack reference for this. It tightly couples these two stacks and makes stack deletion painful.”

Synthesis issues:

• “The synth output looks correct, but let’s diff it against the deployed stack before we apply: cdk diff.”

Key Collocations

Collocation	Usage context
drop down to an L1	when the L2 abstraction is insufficient
synthesize a stack	converting CDK code to CloudFormation
bootstrap an account	one-time account preparation for CDK
bundle assets	packaging Lambda code or Docker images
reference across stacks	cross-stack output/import pattern
expose a property	when a construct surfaces a config option
escape the abstraction	use an escape hatch to access raw CFN

Practice

Take a CDK construct you’ve written recently — even a simple S3 bucket or Lambda. Write three sentences describing it in English: what level of construct it is, what defaults it sets, and whether you needed any escape hatches. Then write one sentence you might say in a code review about it. Focus on using the collocations from this post rather than translating Ukrainian sentence structures directly.

Bridging the Gap: Understanding Nuance in Feedback

Let’s be honest – even with a solid grasp of the technical concepts behind AWS CDK, communicating effectively about your infrastructure as code can still feel…challenging. The precise language used during code reviews, when explaining design decisions to colleagues, or even just documenting what you’ve built is often incredibly nuanced. For developers whose first language isn’t English, this can be particularly tricky. It’s not simply about knowing the definitions of “construct” and “stack”; it’s about understanding how those words are used in a professional context – the subtle implications behind them.

Imagine receiving a code review comment like this: “This CDKConstruct definition is overly verbose. Consider refactoring to utilize more concise, declarative syntax for improved readability.” At first glance, it seems straightforward, but what does “verbose” really mean in this situation? It doesn’t just imply length; it suggests the code isn’t as clear or efficient as it could be. Similarly, a Slack message asking “Can you explain the rationale behind deploying the Lambda function directly within the stack?” demands more than just a yes/no answer. The question probes for why that particular choice was made – the underlying design considerations. The key is recognizing that these phrases aren’t arbitrary; they carry specific expectations about clarity, maintainability, and accountability. Learning to interpret them accurately is crucial. It’s also important to understand the difference between stating a problem (“This doesn’t meet our security requirements”) and proposing a solution (“Let’s implement an IAM role with least privilege access”).

Another common scenario involves writing PR descriptions. A good description isn’t just a list of changes; it’s a narrative that explains what was changed, why it was changed, and how it contributes to the overall project goals. For example: “Implemented a new S3 bucket policy to restrict access to sensitive data within the application stack. This aligns with our organization’s security best practices and mitigates potential risks associated with unauthorized data retrieval.” Notice how this description uses phrases like “mitigates potential risks” – a common way of framing technical improvements in business terms, emphasizing their value.

// Example CDK Construct - S3 Bucket Creation
import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';

export class MyS3Bucket extends cdk.Construct {
  public readonly bucket: s3.Bucket;

  private constructor(scope: cdk.Scope, id: string) {
    super(scope, id);
    this.bucket = new s3.Bucket(this, 'MyBucket', {
      removalPolicy: cdk.RemovalPolicy.DESTROY, // Important for cleanup!
    });
  }
}

Ultimately, building proficiency in this area is about observation and active listening. Pay attention to how senior engineers communicate, ask questions, and provide feedback. Don’t hesitate to politely clarify when something isn’t clear – it’s better to ask than to misinterpret a request and potentially introduce unintended consequences.