Hey CDK community! Here's an update covering everything that shipped in April and May 2026.
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).
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 ✓) │
└─────────────────────────────────────────────────────┘
js
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:
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.
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.
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) │ │
│ └────────────────────────┘ │
└──────────────────────────────┘
js
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 severityacknowledge()
to suppress known violations@aws-cdk/core:validationReportJson
context key for machine-readable CI/CD outputThree 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 └─────────┘ │
│ │
└─────────────────────────────────────────┘
| Improvement | Impact | PR |
|---|---|---|
| File fingerprinting ~33% faster | Large apps with hundreds of assets deploy significantly faster | |
If your CI/CD pipeline spends minutes on cdk synth
, these changes deliver immediate time savings with zero code changes — just upgrade.
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.
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)
uuid
dependencynode:crypto
, reducing CLI bundle sizeCDK'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
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.
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)
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.
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.
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.
bucketNamePrefix
& bucketNamespace
properties (** badmintoncryer** (Kazuho Cryer-Shinozuka, Asahi-Kasei) — The period's most prolific external contributor with 5 features spanning ALB JWT authentication (
** mazyu36** — 11 contributions including Synthetics canary groups (
** msambol** (Workday) — Created the entire Aurora DSQL alpha module from scratch (
** go-to-k** (Kenta Goto) — Built
cdk publish-assets
(eliasbrange, dineshSajwan, kawaaaas, aayushostwal, yasomaru, jasdeepbhalla, yatakemi, Ronitsabhaya75, clayrosenthal, camerondurham, tomohiro86, mellevanderlinde, naviret, AnnasMazhar, letsgomeow
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:
Open an issue on GitHub.
Check our contributing guide and look for good first issue or
help wanted
aws-cdk
tagGive us a star on GitHub! ⭐