devtools #infrastructureascode #cdk #aws

Index

• TL;DR
• Major Features
  • Bedrock AgentCore — From Alpha to Stable
  • Fn::GetStackOutput & Weak Cross-Stack References
  • Validations Framework
  • Performance Improvements
  • CloudWatch PromQL Alarms
  • CLI Improvements
  • New L2 Constructs
  • Service Enhancements
• Community Highlights
• Community Content & Resources
• How Can You Be Involved

Hey CDK community! Here's an update covering everything that shipped in April and May 2026.

TL;DR

Bedrock AgentCore graduated to stable — production-ready AI agent infrastructure with semver guarantees. Cross-region references got a major upgrade with native Fn::GetStackOutput support and weak cross-stack references. The new Validations framework replaces policyValidationBeta1 with a richer plugin system. And file fingerprinting is ~33% faster with persistent asset caching.

These features are available in aws-cdk-lib v2.247.0 through v2.257.0 and aws-cdk CLI v2.1116.0 through v2.1125.0. Full changelogs on GitHub Releases (Library | CLI).

Major Features

Bedrock AgentCore — From Alpha to Stable

The @aws-cdk/aws-bedrock-agentcore-alpha module has graduated to aws-cdk-lib/aws-bedrockagentcore — stable APIs, semver guarantees, production-ready. If you've been building AI agents with Bedrock but held off on CDK because of the alpha label, it's time to upgrade. (#37876)

AgentCore provides the core infrastructure for building AI agents: runtimes, gateways, identity management, observability, and online evaluation. The Policy submodule remains in alpha as it continues to evolve rapidly.

┌─────────────────────────────────────────────────────┐
│              Bedrock AgentCore (Stable)              │
├─────────────────────────────────────────────────────┤
│                                                     │
│  ┌──────────┐  ┌──────────┐  ┌──────────────────┐  │
│  │ Runtime  │  │ Gateway  │  │    Identity       │  │
│  │  (L2)    │  │  (L2)    │  │     (L2)         │  │
│  └────┬─────┘  └────┬─────┘  └────────┬─────────┘  │
│       │              │                 │            │
│       ▼              ▼                 ▼            │
│  ┌──────────┐  ┌──────────┐  ┌──────────────────┐  │
│  │Observa-  │  │Online    │  │  Policy Engine   │  │
│  │bility    │  │Evaluation│  │   (⚠️ Alpha)     │  │
│  └──────────┘  └──────────┘  └──────────────────┘  │
│                                                     │
├─────────────────────────────────────────────────────┤
│  @aws-cdk/alpha  ──▶  aws-cdk-lib (semver ✓)       │
└─────────────────────────────────────────────────────┘

import * as agentcore from 'aws-cdk-lib/aws-bedrockagentcore';

const agentRuntimeArtifact = agentcore.AgentRuntimeArtifact.fromCodeAsset({
  path: path.join(__dirname, 'path/to/agent/code'),
  runtime: agentcore.AgentCoreRuntime.PYTHON_3_12,
  entrypoint: ['opentelemetry-instrument', 'main.py'],
});

const runtimeInstance = new agentcore.Runtime(this, "MyAgentRuntime", {
  runtimeName: "myAgent",
  agentRuntimeArtifact: agentRuntimeArtifact,
});

See aws-bedrockagentcore README for more details.

Also new in AgentCore during this period:

• Identity L2 constructs for multi-tenant agent management
• OnlineEvaluationConfig & Evaluator for quality gates in CI/CD
• Observability for Runtime — logging/tracing configuration
• Policy & Policy Engine L2 constructs (alpha) (dineshSajwan)

Fn::GetStackOutput & Weak Cross-Stack References

Multi-region deployments have long been one of CDK's roughest edges. Two features landed in April/May that fundamentally improve the story:

         BEFORE                          AFTER
┌─────────────────────┐       ┌─────────────────────┐
│  Stack A (us-east-1)│       │  Stack A (us-east-1)│
│  ┌───────────────┐  │       │  ┌───────────────┐  │
│  │ VPC Resource  │  │       │  │ VPC Resource  │  │
│  └───────┬───────┘  │       │  └───────┬───────┘  │
│          │          │       │          │          │
│          ▼          │       │          ▼          │
│  ┌───────────────┐  │       │  ┌───────────────┐  │
│  │Custom Resource│  │       │  │    Output:    │  │
│  │  (Writer)     │  │       │  │    VpcId      │  │
│  └───────┬───────┘  │       │  └───────────────┘  │
└──────────┼──────────┘       └─────────────────────┘
           │                             │
           ▼                             │
   ┌───────────────┐            Fn::GetStackOutput
   │ SSM Parameter │                     │
   │ (us-west-2)   │                     │
   └───────┬───────┘                     │
           │                             │
┌──────────┼──────────┐       ┌──────────┼──────────┐
│          ▼          │       │          ▼          │
│  ┌───────────────┐  │       │  ┌───────────────┐  │
│  │Custom Resource│  │       │  │  Native CFN   │  │
│  │  (Reader)     │  │       │  │  Resolution   │  │
│  └───────────────┘  │       │  └───────────────┘  │
│  Stack B (us-west-2)│       │  Stack B (us-west-2)│
└─────────────────────┘       └─────────────────────┘
  ❌ Slow, complex IAM          ✅ Fast, zero CRs

Fn::GetStackOutput

CloudFormation's new intrinsic function for cross-region and cross-account references is now supported natively in CDK. No more SSM parameters, custom resources, or fragile workarounds. (#37724)

Configure the reference strength in your cdk.json:

{
  "context": {
    "@aws-cdk/core:defaultCrossStackReferences": "weak"
  }
}

Or use the low-level API directly:

const remoteVpcId = Fn.getStackOutput('NetworkStack', 'VpcId', 'us-west-2');

See aws-cdk-lib README for more details.

Previously, enabling crossRegionReferences generated two custom resources communicating via SSM parameters — slow to deploy, complex IAM, and prone to drift. Fn::GetStackOutput is a native CloudFormation mechanism: faster, more reliable, and zero custom resources. For cross-account access, pass a roleArn as the fourth parameter pointing to an IAM role in the target account.

Weak Cross-Stack References

In the same environment, CDK now supports opt-in weak references via the @aws-cdk/core:defaultCrossStackReferences context key. (#37824) When set to "weak", CDK avoids generating unnecessary cross-region exports — meaning faster deploys, simpler IAM, and helping avoid "exports cannot be updated" errors when refactoring stacks. A safe two-step migration path ("both" → "weak") is provided for existing deployments.

Validations Framework

The new Validations class replaces the deprecated policyValidationBeta1 interfaces with a unified post-synthesis validation plugin system: (#37611)

┌──────────────┐
│   cdk synth  │
└──────┬───────┘
       │
       ▼
┌──────────────────────────────┐
│      Cloud Assembly          │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│     Validations Engine       │
│                              │
│  ┌────────┐  ┌────────────┐ │
│  │Plugin A│  │  Plugin B  │ │
│  └───┬────┘  └─────┬──────┘ │
│      │              │        │
│      ▼              ▼        │
│  ┌────────┐  ┌────────────┐ │
│  │Warning │  │   Error    │ │
│  └────────┘  └────────────┘ │
│                     │        │
│         acknowledge()        │
│              │               │
│              ▼               │
│  ┌────────────────────────┐ │
│  │  Suppressed (known)    │ │
│  └────────────────────────┘ │
└──────────────────────────────┘

const app = new App();

// Register validation plugins globally
Validations.of(app).addPlugins(new MyCompliancePlugin());

// Only apply to a particular stage
const prodStage = new Stage(app, 'ProdStage');
Validations.of(prodStage).addPlugins(new ProdCompliancePlugin());

See aws-cdk-lib README for more details.

Key improvements over the old system:

• addWarning() / addError() for graduated severity
• acknowledge() to suppress known violations
• Validation reports automatically written to cloud assembly
• @aws-cdk/core:validationReportJson context key for machine-readable CI/CD output

Performance Improvements

Three changes that make large CDK apps noticeably faster:

┌─────────────────────────────────────────┐
│            cdk synth / deploy           │
├─────────────────────────────────────────┤
│                                         │
│  File Fingerprinting                    │
│  ┌─────────┐         ┌─────────┐       │
│  │ Before  │  ~33%   │  After  │       │
│  │  15s    │────────▶│  10s    │       │
│  └─────────┘  faster └─────────┘       │
│                                         │
│  Asset Cache (2nd deploy)               │
│  ┌─────────┐         ┌─────────┐       │
│  │Unchanged│────────▶│ Skipped │       │
│  │ assets  │  cache  │  (0s)   │       │
│  └─────────┘   hit   └─────────┘       │
│                                         │
│  Slow Synth Diagnostics                 │
│  ┌─────────┐         ┌─────────┐       │
│  │Slow app │────────▶│ Perf    │       │
│  │detected │  auto   │counters │       │
│  └─────────┘  emit   └─────────┘       │
│                                         │
└─────────────────────────────────────────┘

If your CI/CD pipeline spends minutes on cdk synth, these changes deliver immediate time savings with zero code changes — just upgrade.

CloudWatch PromQL Alarms

A new L2 construct lets you define CloudWatch alarms using PromQL expressions — directly targeting metrics ingested through the CloudWatch OTLP endpoint: (#37793)

┌──────────────────┐     ┌──────────────────┐
│  OTLP Metrics    │────▶│   CloudWatch     │
│  (Prometheus)    │     │   Metrics Store  │
└──────────────────┘     └────────┬─────────┘
                                  │
                           PromQL Query
                                  │
                                  ▼
                         ┌──────────────────┐
                         │  PromQL Alarm    │
                         │                  │
                         │ pendingPeriod: 5m│
                         │ recoveryPeriod:5m│
                         └────────┬─────────┘
                                  │
                    ┌─────────────┼─────────────┐
                    ▼             ▼             ▼
              ┌─────────┐  ┌─────────┐  ┌─────────┐
              │   OK    │  │ Pending │  │  Alarm  │
              └─────────┘  └─────────┘  └─────────┘

new cloudwatch.PromQLAlarm(this, 'HighLatencyAlarm', {
  alarmDescription: 'P99 latency exceeds 500ms for 5 minutes',
  query: 'histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 0.5',
  evaluationInterval: Duration.seconds(60),
  pendingPeriod: Duration.seconds(300),
  recoveryPeriod: Duration.seconds(600),
});

See aws-cloudwatch README for more details.

PromQL alarms use duration-based state transitions (pending/recovery periods) instead of the evaluation-period/threshold model of standard CloudWatch alarms. For teams migrating from Prometheus/Grafana, this eliminates the painful translation step — use your existing PromQL queries directly.

CLI Improvements

cdk diagnose

When a stack deployment fails, you no longer need to dig through CloudFormation events in the console. cdk diagnose automatically analyzes failure events and prints a human-readable root cause: (aws-cdk-cli#1378)

$ cdk diagnose MyFailedStack --unstable=diagnose

cdk orphan (Experimental)

Detach a resource from CloudFormation management without deleting the actual AWS resource. Essential for type migrations and logical ID refactors that would otherwise require manual intervention: (aws-cdk-cli#1399)

$ cdk orphan MyStack/MyTable --unstable=orphan

The resource's DeletionPolicy is set to Retain and it's removed from the template. You can then re-import it under a new definition using cdk import.

cdk publish-assets

Separate asset publishing from deployment in your CI/CD pipeline. Build and upload Docker images and Lambda ZIPs without triggering a CloudFormation stack update: (aws-cdk-cli#1020)

$ # Publish assets for a single stack
$ cdk publish-assets MyStack --unstable=publish-assets

$ # Publish assets for all stacks
$ cdk publish-assets --all --unstable=publish-assets

$ # Force re-publish even if assets already exist
$ cdk publish-assets MyStack --unstable=publish-assets --force

(go-to-k)

Additional CLI Updates

• Guard Hook failure details — detailed compliance violation annotations displayed automatically (jkelley-godaddy)
• Empty change set handling — auto-skips deployment confirmation when no resources changed (orien)
• Removed uuid dependency — uses native node:crypto, reducing CLI bundle size

Hotswap with Cloud Control API

CDK's hotswap deployment now supports any resource type via the Cloud Control API (CCAPI). Previously, hotswap only worked with a handful of hard-coded resource types (Lambda, ECS, Step Functions). With the new generic CCAPI infrastructure, any CloudFormation resource type that supports Cloud Control can be hotswapped — cutting iteration time dramatically during development. (aws-cdk-cli#1310)

QuickSight resources (Dashboards, Analyses, Templates, DataSets, DataSources) were the first to take advantage of this, but the door is now open for any CCAPI-compatible resource.

$ cdk deploy --hotswap MyStack

Source Tracing for L1 Property Mutations

When CDK_DEBUG=1 is set, CDK now records stack traces for every L1 construct property mutation. This means when a property has an unexpected value in the synthesized template, you can trace exactly which line of code set it — invaluable for debugging complex constructs with multiple layers of abstraction. (#37543)

$ CDK_DEBUG=1 cdk synth

The trace metadata appears in the cloud assembly, showing the call site where each property was last modified.

New L2 Constructs

Aurora DSQL (Alpha)

An initial L2 construct for Aurora DSQL — AWS's serverless SQL database with DynamoDB-like scalability and PostgreSQL-compatible SQL:

import * as dsql from '@aws-cdk/aws-dsql-alpha';

declare const role: iam.Role;

const cluster = new dsql.Cluster(this, 'MyCluster', {
  clusterName: 'my-dsql-cluster',
  deletionProtection: true,
});

// High-level grants instead of raw IAM policies
cluster.grantConnect(role);      // dsql:DbConnect
cluster.grantConnectAdmin(role); // dsql:DbConnectAdmin

See aws-dsql-alpha README for more details.

(msambol)

MediaPackage V2 (Alpha)

Full-featured L2 for AWS Elemental MediaPackage V2 with OAC integration for CloudFront:

import { ChannelGroup, Channel, OriginEndpoint, Manifest, InputConfiguration, Segment } from '@aws-cdk/aws-mediapackagev2-alpha';

const group = new ChannelGroup(stack, 'MyChannelGroup', {
  channelGroupName: 'my-channel-group',
});

const channel = group.addChannel('MyChannel', {
  channelName: 'my-channel',
  input: InputConfiguration.cmaf(),
});

const endpoint = channel.addOriginEndpoint('MyEndpoint', {
  originEndpointName: 'my-endpoint',
  segment: Segment.cmaf(),
  manifests: [Manifest.hls({ manifestName: 'index' })],
});

See aws-mediapackagev2-alpha README for more details.

Service Enhancements

ALB JWT Authentication

Verify JWTs directly at the load balancer for service-to-service auth — no custom Lambda authorizers needed:

declare const lb: elbv2.ApplicationLoadBalancer;
declare const certificate: acm.Certificate;
declare const myTargetGroup: elbv2.ApplicationTargetGroup;

const listener = lb.addListener('Listener', {
  port: 443,
  certificates: [certificate],
  defaultAction: elbv2.ListenerAction.authenticateJwt({
    issuer: 'https://issuer.example.com',
    jwksEndpoint: 'https://issuer.example.com/.well-known/jwks.json',
    next: elbv2.ListenerAction.forward([myTargetGroup]),
  }),
});

See aws-elasticloadbalancingv2 README for more details.

(badmintoncryer)

Lambda SQS Provisioned Poller

Pre-provision SQS pollers to reduce cold start latency in high-throughput scenarios:

import { SqsEventSource } from 'aws-cdk-lib/aws-lambda-event-sources';

declare const fn: lambda.Function;
declare const queue: sqs.Queue;

fn.addEventSource(new SqsEventSource(queue, {
  batchSize: 10,
  maxBatchingWindow: Duration.minutes(5),
  reportBatchItemFailures: true,
  provisionedPollerConfig: {
    minimumPollers: 2,
    maximumPollers: 10,
  },
}));

See aws-lambda-event-sources README for more details.

(badmintoncryer)

More Service Updates

• Lambda: Ruby 4.0 runtime
• Batch: AL2023 image types as default under feature flag
• ECS: Service Connect access log configuration (badmintoncryer)
• Route53: Accelerated recovery for public hosted zones (badmintoncryer)
• Synthetics: Canary group support (mazyu36), Playwright 5.1 & 6.0 runtimes (yatakemi)
• DynamoDB: Resource policies for streams
• SES: Auto email validation for configuration sets (badmintoncryer)
• EC2: C8A instance type support (aayushostwal)
• S3: bucketNamePrefix & bucketNamespace properties (kawaaaas)
• API Gateway V2: Role support for Lambda authorizers (eliasbrange), auto EventBusName in HTTP EventBridge integration (jasdeepbhalla)
• EMR: Instance fleet priority allocation (Daniel-ZA)

Community Highlights

Top External Contributors

badmintoncryer (Kazuho Cryer-Shinozuka, Asahi-Kasei) — The period's most prolific external contributor with 5 features spanning ALB JWT authentication (#36099), ECS Service Connect access logs (#36067), Route53 accelerated recovery (#36358), SES auto email validation (#36679), and Lambda SQS provisioned poller (#37550). A consistent driving force behind CDK's service coverage.

mazyu36 — 11 contributions including Synthetics canary groups (#35689), Bedrock model updates (#36898, #37623), and ElastiCache improvements (#37816). One of the most prolific community contributors this period.

msambol (Workday) — Created the entire Aurora DSQL alpha module from scratch (#34599). A distinguished-contributor showing how organizations outside AWS drive new module creation.

go-to-k (Kenta Goto) — Built cdk publish-assets (aws-cdk-cli#1020), enabling a long-requested CI/CD optimization. Also contributed concurrent asset builds (aws-cdk-cli#983) in the previous period.

Additional Contributors

eliasbrange, dineshSajwan, kawaaaas, aayushostwal, yasomaru, jasdeepbhalla, yatakemi, Ronitsabhaya75, clayrosenthal, camerondurham, tomohiro86, mellevanderlinde, naviret, AnnasMazhar, letsgomeow

Community Content & Resources

From the Community:

Fn::GetStackOutput: How CloudFormation and CDK Solved Cross-Region References Together — Pahud Hsieh deep-dives into how Fn::GetStackOutput works and what it means for multi-region CDK apps. The most popular CDK community post this period.

AI Can't Fix What It Can't See: How cdk diagnose Enables Autonomous CDK Remediation — Pahud Hsieh explores how cdk diagnose enables AI-powered infrastructure remediation workflows.

From Manual to Intent: 7 Years of CDK Contribution — Pahud Hsieh reflects on the evolution of CDK and infrastructure-as-code over seven years.

S3 Account Regional Namespaces with CDK — Sean Boult (AWS) explains S3 bucket regional namespace challenges and CDK solutions — directly related to the new bucketNamePrefix feature in v2.256.0.

Enterprise AWS CDK: Architecting a Secure and Scalable Serverless API — Dickson walks through enterprise-grade CDK architecture patterns for serverless APIs.

Content from AWS:

Streamlining Cloud Compliance at GoDaddy Using CDK Aspects — GoDaddy's Jasdeep Singh Bhalla on using CDK Aspects for organization-wide compliance — timely with the new Validations framework.

Announcing AWS CDK Mixins: Composable Abstractions for AWS Resources — Official AWS blog on CDK Mixins, which went stable in March and continues to gain adoption.

Resources:

• AWS IaC MCP Server — AI-powered CDK development via Model Context Protocol.
• Agent Toolkit for AWS — Build AI agents that interact with AWS services, with a dedicated AWS CDK skill for infrastructure-as-code generation.
• CDK Construct Hub — Discover community-built constructs.
• AWS CDK API Reference

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

• Slack: CDK.dev community
• GitHub: Discussions
• Stack Overflow: aws-cdk tag

Star the Repo

Give us a star on GitHub! ⭐