DEV Community

Pahud Hsieh
Pahud Hsieh

Posted on

CDK update - June 2026

Index

Hey CDK community! Here's an update on everything that shipped in June 2026.

TL;DR

Runtime.NODEJS_LATEST now resolves to Node.js 24.x — callback-style Lambda handlers will break. Action required if you use NODEJS_LATEST. On the positive side: the new cdk explore command gives you a visual web UI for browsing your Cloud Assembly, the experimental cdk validate command lets you run validation plugins without a full deploy cycle, and token resolution is ~25% faster.

These features are available in aws-cdk-lib v2.258.0 through v2.260.0 and aws-cdk CLI v2.1126.0 through v2.1128.1. Full changelogs on GitHub Releases (Library | CLI).

Major Features

⚠️ Lambda Node.js 24.x — Action Required

Runtime.NODEJS_LATEST now resolves to nodejs24.x in every region (#38031). This affects Lambda functions and custom resources that use the default runtime.

What breaks: Node.js 24 removes support for callback-style asynchronous handlers. If your Lambda code uses (event, context, callback) => {...}, it will fail at runtime after the bump.

What to do:

  • Migrate to async handlers: async (event, context) => {...}
  • Or pin your runtime explicitly: Runtime.NODEJS_22_X (or useLatestRuntimeVersion: false in NodejsFunction)
// ❌ This will break on Node.js 24
exports.handler = (event, context, callback) => {
  callback(null, { statusCode: 200 });
};

// ✅ Use async instead
exports.handler = async (event, context) => {
  return { statusCode: 200 };
};
Enter fullscreen mode Exit fullscreen mode

Lambda accepts runtime updates in place — existing functions synthesized with NODEJS_LATEST will see nodejs22.xnodejs24.x on the next deploy, no recreation needed. But callback-based handlers must be updated before upgrading. See the Node.js 24 launch blog for details.

cdk explore — Visual Cloud Assembly Browser

A brand-new command that launches a local web server for exploring your synthesized Cloud Assembly (#1578, #1598):

$ cdk explore
Enter fullscreen mode Exit fullscreen mode

Browse stack resources, view synthesized templates, and navigate between your source and the generated CloudFormation — all in a visual interface built on Cloudscape (#1606). The same work also landed an LSP foundation that surfaces validation violations and CFN resources in your editor (#1592), CodeLens navigation with template resource locations (#1617), two-way template/source navigation (#1624), and diagnostics that refresh automatically when cdk.out changes (#1630). See the cdk-explorer README for the full feature set.

cdk validate — Standalone Validation Command

An experimental cdk validate command landed (#1527), letting you run validation plugins against your synthesized templates as a standalone step. A follow-up added --online mode (#1539), which dynamically fetches the latest validation rules from remote sources instead of relying on locally installed rule sets. The command is still experimental as it matures — watch the CLI changelog as it evolves.

Performance Improvements

Improvement Impact PR
Token resolution ~25% faster Synthesis time reduced for token-heavy apps #37920
Performance counters for slow synth Auto-emits diagnostics when synthesis is slow #38004
Docker build cache skip Bundling correctly skips rebuild when the image is already built #38134

Combined with April/May's file-fingerprinting improvements, large CDK apps now synthesize noticeably faster than they did three months ago.

Cross-Stack Reference Strength Controls

Building on April/May's Fn::GetStackOutput and weak cross-stack references, June added fine-grained control over reference strength (#37840), and CDK now recommends weak references when no explicit choice has been made (#38070). A fix also landed for weak references to list attributes (#37948).

Set the app-wide default in cdk.json:

{
  "context": {
    "@aws-cdk/core:defaultCrossStackReferences": "weak"
  }
}
Enter fullscreen mode Exit fullscreen mode

See Reference strength in the aws-cdk-lib README for the strong/both/weak comparison table and the recommended migration path out of the "deadly embrace."

Validation Framework Evolution

The Validations framework introduced in April/May continues to mature with four improvements:

  • New validation report schema — more structured, easier for CI/CD tools to consume (#37970)
  • Plugins can create files in the cloud assembly — compliance tools can generate audit reports directly (#38007)
  • Suppressed violations included in validation-report.json — full audit trail of deliberately ignored issues (#38009)
  • Scope added to IPolicyValidationContext — enables scope-based validation rules (#38006)

CLI Improvements

--debug-app and --debug-cli

The old --debug flag has been split into targeted options (#1604): --debug-app shows only synthesis-related output (your CDK app logic), while --debug-cli shows CLI internals.

ECS and Custom Resource Failure Logs

When deployments fail due to ECS service issues or custom resource Lambda errors, the CLI now automatically fetches and displays the relevant logs — no more switching to CloudWatch to find out what went wrong. Detailed ECS service and container-level logs landed in #1505, and custom resource Lambda logs in #1645.

Additional CLI Updates

  • Asset packaging dependencies reduced by ~48 — faster installs, smaller bundle, reduced supply chain risk (#1654)
  • cdk init project name fix--project-name now correctly maps to generated files (#1644, TORIFUKUKaiou)
  • Custom role session names — set CDK_ROLE_SESSION_NAME to control the assumed-role session name (#1672, UTKARSH698)
  • cdk list stdout fix — output no longer includes synthesis timing or dependency status lines, making it reliable for scripting (#1637, #1663)
  • Telemetry proxy support — telemetry now respects configured network proxies (#1577)
  • Deletion failures in DeployResult — programmatic toolkit users can now see which stacks failed to delete (#1576)

Service Enhancements

EKS AL2023 Default

EKS node groups now default to Amazon Linux 2023 AMIs (under feature flag) instead of AL2 (#37850) — better security posture out of the box.

EKS Cluster Deletion Protection

The Cluster construct now supports deletionProtection (#36474):

new eks.Cluster(this, 'HelloEKS', {
  version: eks.KubernetesVersion.V1_35,
  kubectlLayer: new KubectlV35Layer(this, 'kubectl'),
  deletionProtection: true,
});
Enter fullscreen mode Exit fullscreen mode

Contributed by: matoom-nomu

ECS Force New Deployment

Trigger a redeployment without changing the task definition — useful for pulling the latest image with the same tag (#36797):

declare const cluster: ecs.Cluster;
declare const taskDefinition: ecs.TaskDefinition;

const service = new ecs.FargateService(this, 'Service', {
  cluster,
  taskDefinition,
});

// Force a new deployment with an auto-generated nonce (deploys on every `cdk deploy`)
service.forceNewDeployment();

// Or provide your own nonce to control when deployments are triggered
service.forceNewDeployment('my-custom-nonce-v2');
Enter fullscreen mode Exit fullscreen mode

Contributed by: yasomaru

More Service Updates

  • EKS: ALB Controller versions v2.8.3 through v3.2.2 supported (#37752)
  • ElastiCache: CacheEngine/UserEngine enums replaced with enum-like classes for future extensibility (#37816)
  • Bedrock AgentCore: default endpoint application log group exposed on Runtime (#37812)
  • Lambda Node.js bundling: entry paths containing .. no longer rejected (#38022, vishwakt)
  • Core: property assignments traced in CfnResource.addPropertyOverride (#38072), external stack traces appended to construct metadata (#38124, #38131)

Community Highlights

External Contributors

matoom-nomu (valued-contributor) — EKS deletionProtection property (#36474). Enterprise contributors bringing real-world production needs to CDK.

yasomaru — ECS forceNewDeployment for Fargate and EC2 services (#36797), resolving a long-standing feature request (#27762).

UTKARSH698 — Customizable role session names via CDK_ROLE_SESSION_NAME (#1672) — a real quality-of-life win for audit trails in multi-account setups.

vishwakt (beginning-contributor) — Fixed Lambda Node.js bundling rejecting entry paths containing .. (#38022), unblocking monorepo users.

TORIFUKUKaiou — Fixed cdk init project-name argument mapping (#1644). Quality-of-life improvements matter.

Tietew (distinguished-contributor) — Kept RDS engine versions current with Aurora PostgreSQL 16.13 limitless and new MySQL versions (#38053, #38039).

camiloaz (beginning-contributor) — Added the EC2 g7e instance class (NVIDIA Blackwell B200) (#37971).

syukawa-gh (admired-contributor) — Fixed grammar errors and typos across source comments (#37577).

MaxwellM34 (beginning-contributor) — Fixed an awslint rule reference in the docs (#38150) — first contribution, welcome!

Community Content & Resources

From the Community:

Understanding AWS Blocks as a CDK Developer — Kenta Goto (AWS Hero) analyzes the AWS Blocks preview from a CDK developer's perspective — how it complements rather than replaces CDK.

What is AWS Blocks? How it differs from Amplify and App Studio — Kento IKEDA (AWS Community Builder) compares AWS Blocks vs Amplify vs App Studio after the June announcement.

We Replaced 20% of Our Lambda Functions with CDK Constructs — And Saved $12,000 on AWS Bills — Dinesh Gowtham shares concrete cost savings from CDK construct refactoring.

CDK Deploy-Twice: When Your Infrastructure Needs to Know About Itself — Joanne Skiles (AWS Community Builder) explains a common CDK pain point for new users.

The Bucket That Wouldn't Die: A CDK Insights Origin Story — Lee Priest (AWS Community Builder) on the S3 bucket deletion pain that inspired a CDK tooling project.

Resources:

🔮 Spoiler

Coming up: a brand-new blog post introducing the new CDK comprehensive validation. Stay tuned — don't miss it!

How Can You Be Involved

Report Issues

Open an issue on GitHub.

Contribute Code

Check our contributing guide and look for good first issue or help wanted labels.

Join the Conversation

Star the Repo

Give us a star on GitHub! ⭐

Feedback? Share in GitHub Discussions.

Top comments (0)