You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Improve cdk diff Performance with Parallel Change Set Creation #1946
cdk diff does not provide an option to configure parallelism for creating change sets. Unlike cdk deploy, which supports the --concurrency option, change-set creation during cdk diff cannot be configured to run in parallel. As a result, repositories with more than 100 stacks can take a significant amount of time to generate the change sets, impacting the overall cdk diff execution time.
Use Case
If we have 100+ stacks in the repository, cdk diff take significant amount of time to generate the change sets
Proposed Solution
No response
Other Information
No response
Acknowledgements
I may be able to implement this feature request
This feature might incur a breaking change
AWS CDK Library version (aws-cdk-lib)
2.263.0
AWS CDK CLI version
2.1135.0
Environment details (OS name and version, etc.)
macOS 26.6.2
Reacted by rittneje, Riccardo Albertazzi and ikngm
┌────────────────────────────────────────────────────────────┐
│ 🔴 Reported State │
│ Diff change sets run one stack at a time │
└─────────────────────────────┬──────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────┐
│ 🔍 Root Cause │
│ Diff has no concurrency option or bounded parallel path │
└─────────────────────────────┬──────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────────┐
│ 🟢 Suggested Fix │
│ Add opt-in bounded concurrency with stable output │
└────────────────────────────────────────────────────────────┘
I was able to reproduce the configuration gap on macOS with the reported AWS CDK CLI 2.1135.0 and aws-cdk-lib 2.263.0. I then repeated the same check with the latest releases, AWS CDK CLI 2.1140.0 and aws-cdk-lib 2.268.0, with the same result: cdk diff --help has no concurrency option, and passing --concurrency 2 prints that the option is unknown and ignored before diffing both stacks and exiting successfully. I used --change-set=false for these local reproductions, so I did not create cloud resources or benchmark the reported 100-plus-stack latency.
It appears the request matches the current implementation. CdkToolkit.diff() iterates over stacks and awaits each deployed-template read and diff change-set creation before advancing:
awaitthis.ioHost.asIoHelper().defaults.warn('This deployment will make potentially sensitive changes according to your current security approval level.\nPlease confirm you intend to make the following modifications:\n');
If lower-fidelity replacement analysis is acceptable, cdk diff --method=template is available today and is documented as faster but less accurate. If you require change-set accuracy, that workaround does not cover the use case.
From my view, this is a valid unresolved feature request. A compatible design would add an opt-in diff concurrency value defaulting to 1, perform bounded parallel stack preparation, and preserve deterministic output plus cleanup/fallback behavior. Because the implementation is in aws/aws-cdk-cli, I am transferring this issue there. Contributions would be welcome, particularly with tests for concurrency bounds, CloudFormation throttling/failures, output ordering, nested stacks, and change-set cleanup.
Implemented the bounded opt-in concurrency path in draft PR #2031, for both CLI diff and toolkit-lib. Default concurrency remains 1; concurrent preparation preserves ordered notifications/results, stops queued work after failure and waits for in-flight cleanup. Local validation passed 92 toolkit tests and 108 CLI tests, compilation, API Extractor and scoped lint. Tests include a simulated 125-stack workload, throttling fallback/strict failure, nested stacks, ordering and cleanup. A live concurrent independent/nested-stack integration test is included but not yet run; no AWS latency benchmark is claimed.
Activity
pahud commentedon Sep 4, 2026
Hi @sonal-aws,
I was able to reproduce the configuration gap on macOS with the reported AWS CDK CLI 2.1135.0 and
aws-cdk-lib2.263.0. I then repeated the same check with the latest releases, AWS CDK CLI 2.1140.0 andaws-cdk-lib2.268.0, with the same result:cdk diff --helphas no concurrency option, and passing--concurrency 2prints that the option is unknown and ignored before diffing both stacks and exiting successfully. I used--change-set=falsefor these local reproductions, so I did not create cloud resources or benchmark the reported 100-plus-stack latency.It appears the request matches the current implementation.
CdkToolkit.diff()iterates over stacks and awaits each deployed-template read and diff change-set creation before advancing:aws-cdk-cli/packages/aws-cdk/lib/cli/cdk-toolkit.ts
Lines 340 to 394 in 0fa27ff
Current toolkit-lib retains the same sequential shape in
cfnDiff(), and latest CLI 2.1140.0 still does not expose diff concurrency:aws-cdk-cli/packages/@aws-cdk/toolkit-lib/lib/actions/diff/private/helpers.ts
Lines 63 to 126 in 5b77563
If lower-fidelity replacement analysis is acceptable,
cdk diff --method=templateis available today and is documented as faster but less accurate. If you require change-set accuracy, that workaround does not cover the use case.From my view, this is a valid unresolved feature request. A compatible design would add an opt-in diff concurrency value defaulting to
1, perform bounded parallel stack preparation, and preserve deterministic output plus cleanup/fallback behavior. Because the implementation is inaws/aws-cdk-cli, I am transferring this issue there. Contributions would be welcome, particularly with tests for concurrency bounds, CloudFormation throttling/failures, output ordering, nested stacks, and change-set cleanup.proton0210 commentedon Oct 8, 2026
Implemented the bounded opt-in concurrency path in draft PR #2031, for both CLI diff and toolkit-lib. Default concurrency remains 1; concurrent preparation preserves ordered notifications/results, stops queued work after failure and waits for in-flight cleanup. Local validation passed 92 toolkit tests and 108 CLI tests, compilation, API Extractor and scoped lint. Tests include a simulated 125-stack workload, throttling fallback/strict failure, nested stacks, ordering and cleanup. A live concurrent independent/nested-stack integration test is included but not yet run; no AWS latency benchmark is claimed.