{"slug": "cdk-update-april-may-2026", "title": "CDK Update - April/May 2026", "summary": "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.", "body_md": "Hey CDK community! Here's an update covering everything that shipped in April and May 2026.\n\nBedrock AgentCore graduated to stable — production-ready AI agent infrastructure with semver guarantees. Cross-region references got a major upgrade with native `Fn::GetStackOutput`\n\nsupport and weak cross-stack references. The new Validations framework replaces `policyValidationBeta1`\n\nwith a richer plugin system. And file fingerprinting is ~33% faster with persistent asset caching.\n\nThese features are available in `aws-cdk-lib`\n\nv2.247.0 through v2.257.0 and `aws-cdk`\n\nCLI 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)).\n\nThe `@aws-cdk/aws-bedrock-agentcore-alpha`\n\nmodule has graduated to `aws-cdk-lib/aws-bedrockagentcore`\n\n— 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))\n\nAgentCore 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.\n\n```\n┌─────────────────────────────────────────────────────┐\n│              Bedrock AgentCore (Stable)              │\n├─────────────────────────────────────────────────────┤\n│                                                     │\n│  ┌──────────┐  ┌──────────┐  ┌──────────────────┐  │\n│  │ Runtime  │  │ Gateway  │  │    Identity       │  │\n│  │  (L2)    │  │  (L2)    │  │     (L2)         │  │\n│  └────┬─────┘  └────┬─────┘  └────────┬─────────┘  │\n│       │              │                 │            │\n│       ▼              ▼                 ▼            │\n│  ┌──────────┐  ┌──────────┐  ┌──────────────────┐  │\n│  │Observa-  │  │Online    │  │  Policy Engine   │  │\n│  │bility    │  │Evaluation│  │   (⚠️ Alpha)     │  │\n│  └──────────┘  └──────────┘  └──────────────────┘  │\n│                                                     │\n├─────────────────────────────────────────────────────┤\n│  @aws-cdk/alpha  ──▶  aws-cdk-lib (semver ✓)       │\n└─────────────────────────────────────────────────────┘\njs\nimport * as agentcore from 'aws-cdk-lib/aws-bedrockagentcore';\n\nconst agentRuntimeArtifact = agentcore.AgentRuntimeArtifact.fromCodeAsset({\n  path: path.join(__dirname, 'path/to/agent/code'),\n  runtime: agentcore.AgentCoreRuntime.PYTHON_3_12,\n  entrypoint: ['opentelemetry-instrument', 'main.py'],\n});\n\nconst runtimeInstance = new agentcore.Runtime(this, \"MyAgentRuntime\", {\n  runtimeName: \"myAgent\",\n  agentRuntimeArtifact: agentRuntimeArtifact,\n});\n```\n\nSee [aws-bedrockagentcore README](https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-bedrockagentcore/README.md) for more details.\n\nAlso new in AgentCore during this period:\n\nMulti-region deployments have long been one of CDK's roughest edges. Two features landed in April/May that fundamentally improve the story:\n\n```\n         BEFORE                          AFTER\n┌─────────────────────┐       ┌─────────────────────┐\n│  Stack A (us-east-1)│       │  Stack A (us-east-1)│\n│  ┌───────────────┐  │       │  ┌───────────────┐  │\n│  │ VPC Resource  │  │       │  │ VPC Resource  │  │\n│  └───────┬───────┘  │       │  └───────┬───────┘  │\n│          │          │       │          │          │\n│          ▼          │       │          ▼          │\n│  ┌───────────────┐  │       │  ┌───────────────┐  │\n│  │Custom Resource│  │       │  │    Output:    │  │\n│  │  (Writer)     │  │       │  │    VpcId      │  │\n│  └───────┬───────┘  │       │  └───────────────┘  │\n└──────────┼──────────┘       └─────────────────────┘\n           │                             │\n           ▼                             │\n   ┌───────────────┐            Fn::GetStackOutput\n   │ SSM Parameter │                     │\n   │ (us-west-2)   │                     │\n   └───────┬───────┘                     │\n           │                             │\n┌──────────┼──────────┐       ┌──────────┼──────────┐\n│          ▼          │       │          ▼          │\n│  ┌───────────────┐  │       │  ┌───────────────┐  │\n│  │Custom Resource│  │       │  │  Native CFN   │  │\n│  │  (Reader)     │  │       │  │  Resolution   │  │\n│  └───────────────┘  │       │  └───────────────┘  │\n│  Stack B (us-west-2)│       │  Stack B (us-west-2)│\n└─────────────────────┘       └─────────────────────┘\n  ❌ Slow, complex IAM          ✅ Fast, zero CRs\n```\n\n`Fn::GetStackOutput`\n\nCloudFormation'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))\n\nConfigure the reference strength in your `cdk.json`\n\n:\n\n```\n{\n  \"context\": {\n    \"@aws-cdk/core:defaultCrossStackReferences\": \"weak\"\n  }\n}\n```\n\nOr use the low-level API directly:\n\n``` js\nconst remoteVpcId = Fn.getStackOutput('NetworkStack', 'VpcId', 'us-west-2');\n```\n\nSee [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.\n\nPreviously, enabling `crossRegionReferences`\n\ngenerated two custom resources communicating via SSM parameters — slow to deploy, complex IAM, and prone to drift. `Fn::GetStackOutput`\n\nis a native CloudFormation mechanism: faster, more reliable, and zero custom resources. For cross-account access, pass a `roleArn`\n\nas the fourth parameter pointing to an IAM role in the target account.\n\nIn the same environment, CDK now supports opt-in weak references via the `@aws-cdk/core:defaultCrossStackReferences`\n\ncontext key. ([#37824](https://github.com/aws/aws-cdk/pull/37824)) When set to `\"weak\"`\n\n, 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\"`\n\n→ `\"weak\"`\n\n) is provided for existing deployments.\n\nThe new `Validations`\n\nclass replaces the deprecated `policyValidationBeta1`\n\ninterfaces with a unified post-synthesis validation plugin system: ([#37611](https://github.com/aws/aws-cdk/pull/37611))\n\n```\n┌──────────────┐\n│   cdk synth  │\n└──────┬───────┘\n       │\n       ▼\n┌──────────────────────────────┐\n│      Cloud Assembly          │\n└──────────────┬───────────────┘\n               │\n               ▼\n┌──────────────────────────────┐\n│     Validations Engine       │\n│                              │\n│  ┌────────┐  ┌────────────┐ │\n│  │Plugin A│  │  Plugin B  │ │\n│  └───┬────┘  └─────┬──────┘ │\n│      │              │        │\n│      ▼              ▼        │\n│  ┌────────┐  ┌────────────┐ │\n│  │Warning │  │   Error    │ │\n│  └────────┘  └────────────┘ │\n│                     │        │\n│         acknowledge()        │\n│              │               │\n│              ▼               │\n│  ┌────────────────────────┐ │\n│  │  Suppressed (known)    │ │\n│  └────────────────────────┘ │\n└──────────────────────────────┘\njs\nconst app = new App();\n\n// Register validation plugins globally\nValidations.of(app).addPlugins(new MyCompliancePlugin());\n\n// Only apply to a particular stage\nconst prodStage = new Stage(app, 'ProdStage');\nValidations.of(prodStage).addPlugins(new ProdCompliancePlugin());\n```\n\nSee [aws-cdk-lib README](https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/README.md#policy-validation) for more details.\n\nKey improvements over the old system:\n\n`addWarning()`\n\n/ `addError()`\n\nfor graduated severity`acknowledge()`\n\nto suppress known violations`@aws-cdk/core:validationReportJson`\n\ncontext key for machine-readable CI/CD outputThree changes that make large CDK apps noticeably faster:\n\n```\n┌─────────────────────────────────────────┐\n│            cdk synth / deploy           │\n├─────────────────────────────────────────┤\n│                                         │\n│  File Fingerprinting                    │\n│  ┌─────────┐         ┌─────────┐       │\n│  │ Before  │  ~33%   │  After  │       │\n│  │  15s    │────────▶│  10s    │       │\n│  └─────────┘  faster └─────────┘       │\n│                                         │\n│  Asset Cache (2nd deploy)               │\n│  ┌─────────┐         ┌─────────┐       │\n│  │Unchanged│────────▶│ Skipped │       │\n│  │ assets  │  cache  │  (0s)   │       │\n│  └─────────┘   hit   └─────────┘       │\n│                                         │\n│  Slow Synth Diagnostics                 │\n│  ┌─────────┐         ┌─────────┐       │\n│  │Slow app │────────▶│ Perf    │       │\n│  │detected │  auto   │counters │       │\n│  └─────────┘  emit   └─────────┘       │\n│                                         │\n└─────────────────────────────────────────┘\n```\n\n| Improvement | Impact | PR |\n|---|---|---|\n| File fingerprinting ~33% faster | Large apps with hundreds of assets deploy significantly faster |\n|\n\nIf your CI/CD pipeline spends minutes on `cdk synth`\n\n, these changes deliver immediate time savings with zero code changes — just upgrade.\n\nA 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))\n\n```\n┌──────────────────┐     ┌──────────────────┐\n│  OTLP Metrics    │────▶│   CloudWatch     │\n│  (Prometheus)    │     │   Metrics Store  │\n└──────────────────┘     └────────┬─────────┘\n                                  │\n                           PromQL Query\n                                  │\n                                  ▼\n                         ┌──────────────────┐\n                         │  PromQL Alarm    │\n                         │                  │\n                         │ pendingPeriod: 5m│\n                         │ recoveryPeriod:5m│\n                         └────────┬─────────┘\n                                  │\n                    ┌─────────────┼─────────────┐\n                    ▼             ▼             ▼\n              ┌─────────┐  ┌─────────┐  ┌─────────┐\n              │   OK    │  │ Pending │  │  Alarm  │\n              └─────────┘  └─────────┘  └─────────┘\nnew cloudwatch.PromQLAlarm(this, 'HighLatencyAlarm', {\n  alarmDescription: 'P99 latency exceeds 500ms for 5 minutes',\n  query: 'histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 0.5',\n  evaluationInterval: Duration.seconds(60),\n  pendingPeriod: Duration.seconds(300),\n  recoveryPeriod: Duration.seconds(600),\n});\n```\n\nSee [aws-cloudwatch README](https://github.com/aws/aws-cdk/blob/main/packages/aws-cdk-lib/aws-cloudwatch/README.md#promql-alarms) for more details.\n\nPromQL 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.\n\n`cdk diagnose`\n\nWhen a stack deployment fails, you no longer need to dig through CloudFormation events in the console. `cdk diagnose`\n\nautomatically analyzes failure events and prints a human-readable root cause: ([aws-cdk-cli#1378](https://github.com/aws/aws-cdk-cli/pull/1378))\n\n``` bash\n$ cdk diagnose MyFailedStack --unstable=diagnose\n```\n\n`cdk orphan`\n\n(Experimental)\nDetach 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))\n\n``` bash\n$ cdk orphan MyStack/MyTable --unstable=orphan\n```\n\nThe resource's `DeletionPolicy`\n\nis set to `Retain`\n\nand it's removed from the template. You can then re-import it under a new definition using `cdk import`\n\n.\n\n`cdk publish-assets`\n\nSeparate 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))\n\n``` bash\n$ # Publish assets for a single stack\n$ cdk publish-assets MyStack --unstable=publish-assets\n\n$ # Publish assets for all stacks\n$ cdk publish-assets --all --unstable=publish-assets\n\n$ # Force re-publish even if assets already exist\n$ cdk publish-assets MyStack --unstable=publish-assets --force\n```\n\n([go-to-k](https://github.com/go-to-k))\n\n`uuid`\n\ndependency`node:crypto`\n\n, 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))\n\nQuickSight 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.\n\n``` bash\n$ cdk deploy --hotswap MyStack\n```\n\nWhen `CDK_DEBUG=1`\n\nis 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))\n\n``` bash\n$ CDK_DEBUG=1 cdk synth\n```\n\nThe trace metadata appears in the cloud assembly, showing the call site where each property was last modified.\n\nAn initial L2 construct for Aurora DSQL — AWS's serverless SQL database with DynamoDB-like scalability and PostgreSQL-compatible SQL:\n\n``` js\nimport * as dsql from '@aws-cdk/aws-dsql-alpha';\n\ndeclare const role: iam.Role;\n\nconst cluster = new dsql.Cluster(this, 'MyCluster', {\n  clusterName: 'my-dsql-cluster',\n  deletionProtection: true,\n});\n\n// High-level grants instead of raw IAM policies\ncluster.grantConnect(role);      // dsql:DbConnect\ncluster.grantConnectAdmin(role); // dsql:DbConnectAdmin\n```\n\nSee [aws-dsql-alpha README](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-dsql-alpha/README.md) for more details.\n\n([msambol](https://github.com/msambol))\n\nFull-featured L2 for AWS Elemental MediaPackage V2 with OAC integration for CloudFront:\n\n``` js\nimport { ChannelGroup, Channel, OriginEndpoint, Manifest, InputConfiguration, Segment } from '@aws-cdk/aws-mediapackagev2-alpha';\n\nconst group = new ChannelGroup(stack, 'MyChannelGroup', {\n  channelGroupName: 'my-channel-group',\n});\n\nconst channel = group.addChannel('MyChannel', {\n  channelName: 'my-channel',\n  input: InputConfiguration.cmaf(),\n});\n\nconst endpoint = channel.addOriginEndpoint('MyEndpoint', {\n  originEndpointName: 'my-endpoint',\n  segment: Segment.cmaf(),\n  manifests: [Manifest.hls({ manifestName: 'index' })],\n});\n```\n\nSee [aws-mediapackagev2-alpha README](https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-mediapackagev2-alpha/README.md) for more details.\n\nVerify JWTs directly at the load balancer for service-to-service auth — no custom Lambda authorizers needed:\n\n``` js\ndeclare const lb: elbv2.ApplicationLoadBalancer;\ndeclare const certificate: acm.Certificate;\ndeclare const myTargetGroup: elbv2.ApplicationTargetGroup;\n\nconst listener = lb.addListener('Listener', {\n  port: 443,\n  certificates: [certificate],\n  defaultAction: elbv2.ListenerAction.authenticateJwt({\n    issuer: 'https://issuer.example.com',\n    jwksEndpoint: 'https://issuer.example.com/.well-known/jwks.json',\n    next: elbv2.ListenerAction.forward([myTargetGroup]),\n  }),\n});\n```\n\nSee [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.\n\nPre-provision SQS pollers to reduce cold start latency in high-throughput scenarios:\n\n``` js\nimport { SqsEventSource } from 'aws-cdk-lib/aws-lambda-event-sources';\n\ndeclare const fn: lambda.Function;\ndeclare const queue: sqs.Queue;\n\nfn.addEventSource(new SqsEventSource(queue, {\n  batchSize: 10,\n  maxBatchingWindow: Duration.minutes(5),\n  reportBatchItemFailures: true,\n  provisionedPollerConfig: {\n    minimumPollers: 2,\n    maximumPollers: 10,\n  },\n}));\n```\n\nSee [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.\n\n`bucketNamePrefix`\n\n& `bucketNamespace`\n\nproperties (** badmintoncryer** (Kazuho Cryer-Shinozuka, Asahi-Kasei) — The period's most prolific external contributor with 5 features spanning ALB JWT authentication (\n\n** mazyu36** — 11 contributions including Synthetics canary groups (\n\n** msambol** (Workday) — Created the entire Aurora DSQL alpha module from scratch (\n\n** go-to-k** (Kenta Goto) — Built\n\n`cdk publish-assets`\n\n([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)\n\n**From the Community:**\n\n** Fn::GetStackOutput: How CloudFormation and CDK Solved Cross-Region References Together** — Pahud Hsieh deep-dives into how\n\n`Fn::GetStackOutput`\n\nworks 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\n\n`cdk diagnose`\n\nenables 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.\n\n** S3 Account Regional Namespaces with CDK** — Sean Boult (AWS) explains S3 bucket regional namespace challenges and CDK solutions — directly related to the new\n\n`bucketNamePrefix`\n\nfeature 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.\n\n**Content from AWS:**\n\n** 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.\n\n** 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.\n\n**Resources:**\n\n[Open an issue](https://github.com/aws/aws-cdk/issues/new/choose) on GitHub.\n\nCheck 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\n\n`help wanted`\n\n`aws-cdk`\n\ntagGive us a star on [GitHub](https://github.com/aws/aws-cdk)! ⭐", "url": "https://wpnews.pro/news/cdk-update-april-may-2026", "canonical_source": "https://dev.to/pahud/cdk-update-aprilmay-2026-1k8h", "published_at": "2026-06-24 18:17:35+00:00", "updated_at": "2026-06-24 18:39:21.223321+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "ai-agents", "ai-infrastructure"], "entities": ["AWS CDK", "Bedrock AgentCore", "Amazon Bedrock", "GitHub", "AWS CloudFormation"], "alternates": {"html": "https://wpnews.pro/news/cdk-update-april-may-2026", "markdown": "https://wpnews.pro/news/cdk-update-april-may-2026.md", "text": "https://wpnews.pro/news/cdk-update-april-may-2026.txt", "jsonld": "https://wpnews.pro/news/cdk-update-april-may-2026.jsonld"}}