AWS CDK: Constructs and Levels

The Building Blocks

Imagine you're building with LEGO. You could work with individual 1×1 bricks (maximum control, maximum effort), or you could use pre-assembled LEGO kits that snap together into recognizable shapes. The AWS CDK works the same way.

The AWS CDK (Cloud Development Kit) is a framework that lets you define cloud resources in code, which it then synthesizes — think of it as compiling — into a standard AWS CloudFormation template. That CloudFormation template is what actually gets deployed to AWS. CDK is a code-to-CloudFormation transpiler with a rich library of abstractions on top.

The core concept is the Construct. Everything in CDK is a construct — a reusable cloud component. Constructs compose: you put constructs inside other constructs to build larger systems. They come in three distinct levels:

L1: Low-Level "Cfn" Resources

A direct 1:1 mapping to a CloudFormation resource type.

• Name: Always starts with Cfn (e.g., s3.CfnBucket, ec2.CfnVpc).
• Pros: Complete control over every property. If CloudFormation supports it, L1 exposes it.
• Cons: Verbose. No defaults. You must configure everything manually, including things like encryption, versioning, and access policies that you'd almost always want enabled.
• When to use: When you need a property that the L2 construct doesn't yet expose, or when you're migrating existing CloudFormation templates into CDK.

L2: High-Level Constructs (The Sweet Spot)

Curated by the AWS CDK team with sensible, security-conscious defaults.

• Name: Normal, readable names (e.g., s3.Bucket, ec2.Vpc, lambda.Function).
• Pros: Includes best practices out of the box — S3 buckets block public access by default, Lambda functions get least-privilege IAM roles automatically. Provides helper methods like bucket.grantRead(lambdaFunction) that wire up IAM permissions in one line.
• Cons: Slightly less granular than L1. Occasionally lags behind new CloudFormation features.
• When to use: The default choice for 90% of CDK work.

L3: Architectural Patterns (Constructs Library / "Patterns")

Pre-built solutions for complete, common architectures.

• Example: ecsPatterns.ApplicationLoadBalancedFargateService
• What it creates: In roughly 5 lines of code, this single construct provisions an Application Load Balancer, an ECS Cluster, a Fargate Service, a Task Definition, a Target Group, Security Groups, IAM Roles, and CloudWatch log groups — all correctly wired together.
• When to use: When your use case matches a well-known pattern exactly. Be cautious: L3 constructs can be opinionated and may be harder to customize when your requirements diverge from the pattern.

// L3 example: A complete load-balanced Fargate service in ~5 lines
import * as ecsPatterns from 'aws-cdk-lib/aws-ecs-patterns';

new ecsPatterns.ApplicationLoadBalancedFargateService(this, 'MyService', {
  cluster: cluster,
  cpu: 512,
  memoryLimitMiB: 1024,
  taskImageOptions: { image: ecs.ContainerImage.fromRegistry('nginx') },
});

Key Point: L2 constructs strike the best balance between control and convenience for most use cases. The real power of CDK emerges when you build your own L2/L3-style constructs that encode your organization's standards — security policies, tagging conventions, monitoring requirements — into reusable classes that any team can instantiate.