add support for excluding custom resource Lambda functions from Inspector scans

[rittneje]

Describe the feature

AWS Inspector costs 30 cents per month per Lambda for standard scanning, and 60 cents per month per Lambda function for code scanning. Due to CDK's reliance on custom resources for several common features, such as setting the log group retention for a Lambda function, the number of CDK-owned functions that we don't care to scan can quickly add up, which adds to the Inspector bill.

AWS Inspector allows us to exclude specific Lambda functions from these scans by tagging them with InspectorExclusion= LambdaStandardScanning and InspectorCodeExclusion=LambdaCodeScanning. However, since CDK creates these custom resource Lambda functions behind the scenes, applying these tags is cumbersome.

Please add support for automatically including these tags on all custom resource Lambda functions that are created internally by CDK.

Use Case

See above.

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

CDK version used

2.74.0

Environment details (OS name and version, etc.)

Alpine 3.17

[pahud]

I guess it's possible to apply those tags to the lambda function behind the custom resource with Aspects or Tags class but I am not 100% sure.

[rittneje]

@pahud Adding tags (which are implemented as an aspect) to resources via an aspect does not work that well in general. And even if we tried to do that I don't know how we could distinguish the CDK-backed lambda functions from our own.

[peterwoodworth]

Adding tags (which are implemented as an aspect) to resources via an aspect does not work that well in general

Can you expand on this?

[rittneje]

@peterwoodworth During synthesis, it recurses through the construct tree, and for each node first fetches the list of aspects and then applies them all by calling their visit method. Consequently, any aspects that get added to a node from another aspect while visiting that node will not be applied. There's even a warning it emits for this situation.

aws-cdk/packages/aws-cdk-lib/core/lib/private/synthesis.ts

Lines 238 to 243 in 133c9b5

	// if an aspect was added to the node while invoking another aspect it will not be invoked, emit a warning
	// the `nestedAspectWarning` flag is used to prevent the warning from being emitted for every child
	if (!nestedAspectWarning && nodeAspectsCount !== aspects.all.length) {
	Annotations.of(construct).addWarning('We detected an Aspect was added via another Aspect, and will not be applied');
	nestedAspectWarning = true;
	}

By the way, the fact that this situation isn't supported is one of the more frustrating parts of attempting to use aspects for anything.