Repository navigation
disable CloudTrail dump by default #2084
Description
Describe the feature
After upgrading from 2.257.0 to 2.269.0, we noticed that cdk deploy now dumps CloudTrail logs to the console upon failure.
This is extremely confusing, as the logs it dumps have nothing at all to do with the failure. I don't know why this feature was added.
Please revert this change, or at least disable it by default.
Use Case
Developers expect the logs from a failure to be useful and pertinent. The CloudTrail logs are rarely related to the failure. Even in the very rare case they are, CDK is dumping them too soon to be of any use.
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.269.0
AWS CDK CLI version
2.269.0
Environment details (OS name and version, etc.)
Alpine 3.24.2
Activity
pahud commentedon Oct 23, 2026
Hi @rittneje,
Thanks for the feedback, that's fair. This output comes from the CDK CLI (added in #1676, shipped in CLI
v2.1134.0), which now runs a CloudTrail lookup after every failed deployment, and there is currently no way to turn it off. Since CloudTrail delivery can lag several minutes, atcdk deploytime the results are often incomplete or not relevant to the failure.We agree there should at least be an opt-out. We'll also consider making it off by default for
cdk deployand keeping it forcdk diagnose. PRs are welcome if you'd like to contribute.rittneje commentedon Oct 23, 2026
@pahud A CloudTrail lookup for what exactly? How can CDK possibly know which CloudTrail logs are even related to the deployment, given that all sorts of things may be happening in the account concurrently? This is exactly what we are seeing - the logs it produces are completely irrelevant.
mrgrain commentedon Oct 30, 2026
I don't think this is decided. We have one data point now. The baseline is that the feature should work as intended. If you @rittneje could be so kind to provide some more details on what is going wrong for you, that'd be great.
rittneje commentedon Nov 1, 2026
@mrgrain I'm not going to provide the specific logs here for privacy/security reasons, but in essence, the actual stack deployment sometimes fails while creating an AWS::ApiGateway::UsagePlan, due to a bug in how CloudFormation handles being throttled by the API Gateway control plane. Then at the end, CDK spits out an irrelevant CloudTrail log.
In one instance, the log was that a Lambda function - which wasn't even part of the stacks being deployed, let alone related to the aforementioned failure - failed on dynamodb:DescribeTable because it was unauthorized.
Clearly the CloudTrail filter is faulty. But also, this change has a fundamental design flaw in that logs do not show up immediately in CloudTrail, so even if the filter were correct, it still wouldn't work reliably during
cdk deploy.I will also note that the CDK logs do not make it clear where the CloudFormation logs end and the CloudTrail logs begin, which makes the irrelevant CloudTrail logs even more confusing.
mrgrain commentedon Nov 2, 2026
Thanks! That's great additional detail and feedback to help us track this down. 👍 I understand you can't share the exact output here.
iankhou commentedon Nov 3, 2026
I was able to reproduce this issue. We use the roles in the deployed stack as a heuristic to filter CloudTrail events. Since we currently include imported roles in that filter, we also capture CloudTrail events that used those shared roles.
There are two changes that I am working on. The first is a fix for this incorrect attribution: #2120
And the second is an opt-out mechanism.