CDK Update - April/May 2026

AWS CDK v2.247.0 through v2.257.0 and CLI v2.1116.0 through v2.1125.0 shipped in April/May 2026, graduating Bedrock AgentCore to stable with production-ready AI agent infrastructure and semver guarantees. Cross-region references received native `Fn::GetStackOutput` support and weak cross-stack references, while a new Validations framework replaced `policyValidationBeta1` with a richer plugin system. File fingerprinting is now approximately 33% faster due to persistent asset caching.

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 https://github.com/aws/aws-cdk/releases | CLI https://github.com/aws/aws-cdk-cli/releases . 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 https://github.com/aws/aws-cdk/pull/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 https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-bedrockagentcore/README.md 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 https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/intrinsic-function-reference-getstackoutput.html for cross-region and cross-account references is now supported natively in CDK. No more SSM parameters, custom resources, or fragile workarounds. 37724 https://github.com/aws/aws-cdk/pull/37724 Configure the reference strength in your cdk.json : { "context": { "@aws-cdk/core:defaultCrossStackReferences": "weak" } } Or use the low-level API directly: js const remoteVpcId = Fn.getStackOutput 'NetworkStack', 'VpcId', 'us-west-2' ; See aws-cdk-lib README https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/README.md cross-stack-reference-strength 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 https://github.com/aws/aws-cdk/pull/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 https://github.com/aws/aws-cdk/pull/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 https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/README.md policy-validation for more details. Key improvements over the old system: addWarning / addError for graduated severity acknowledge 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 https://github.com/aws/aws-cdk/pull/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 https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-cloudwatch/README.md promql-alarms 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 https://github.com/aws/aws-cdk-cli/pull/1378 bash $ 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 https://github.com/aws/aws-cdk-cli/pull/1399 bash $ 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 https://github.com/aws/aws-cdk-cli/pull/1020 bash $ 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 https://github.com/go-to-k uuid dependency node: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 https://github.com/aws/aws-cdk-cli/pull/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. bash $ 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 https://github.com/aws/aws-cdk/pull/37543 bash $ 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: js 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 https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-dsql-alpha/README.md for more details. msambol https://github.com/msambol Full-featured L2 for AWS Elemental MediaPackage V2 with OAC integration for CloudFront: js 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 https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-mediapackagev2-alpha/README.md for more details. Verify JWTs directly at the load balancer for service-to-service auth — no custom Lambda authorizers needed: js 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 https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-elasticloadbalancingv2/README.md authenticate-using-jwt for more details. Pre-provision SQS pollers to reduce cold start latency in high-throughput scenarios: js 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 https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-lambda-event-sources/README.md sqs 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 https://github.com/eliasbrange , dineshSajwan https://github.com/dineshSajwan , kawaaaas https://github.com/kawaaaas , aayushostwal https://github.com/aayushostwal , yasomaru https://github.com/yasomaru , jasdeepbhalla https://github.com/jasdeepbhalla , yatakemi https://github.com/yatakemi , Ronitsabhaya75 https://github.com/Ronitsabhaya75 , clayrosenthal https://github.com/clayrosenthal , camerondurham https://github.com/camerondurham , tomohiro86 https://github.com/tomohiro86 , mellevanderlinde https://github.com/mellevanderlinde , naviret https://github.com/naviret , AnnasMazhar https://github.com/AnnasMazhar , letsgomeow https://github.com/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 https://github.com/aws/aws-cdk/issues/new/choose on GitHub. Check our contributing guide https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md and look for good first issue https://github.com/aws/aws-cdk/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22 or help wanted aws-cdk tagGive us a star on GitHub https://github.com/aws/aws-cdk ⭐