lambda: allow propagating Function tags to LogGroup

[rittneje]

Description

When a lambda function is created via CDK, its LogGroup is not created right away. Instead it typically happens the first time the lambda executes. Consequently, the LogGroup does not have any of the function's tags applied to it. It would be nice if there were a way to mark the function to propagate tags to the LogGroup, perhaps via some custom resource. Ideally, this would be exposed as a mutable property so it can be toggled by an Aspect.

Use Case

We want to be able to easily find LogGroups corresponding to particular lambda function tags via the resource tagging API. In particular, this will allow us to easily find and delete these LogGroups when they are no longer needed.

Proposed Solution

Add a flag to the aws_lambda.Function construct indicating whether tags should be propagated. If so, create a custom resource to create the LogGroup if necessary, and then adjust its tags. It should account for adding new tags, deleting old tags, and modifying existing tags. It may be possible to combine this custom resource with the one that manages the LogGroup retention.

Other information

No response

Acknowledge

• I may be able to implement this feature request
• This feature might incur a breaking change

[jd-carroll]

@nija-at is there any update on this issue? By not having this feature, it becomes very difficult to manage LogGroups within an environment.

Is there a reason the LogGroup isn't created when the Lambda is created? (That seems like it would be an easy fix)

[jd-carroll]

@kaizencc - randomly tagging you on this for some visibility (apologies). Would be great if this could get a second look.

[thomaswr]

Any new info on this issue?
Are there recommended workarounds for now to get correctly tagged lambda log groups?

[Naumel]

This issue has been classified as p2.
We use 👍 s on this issue to help prioritize work, and are happy to re-evaluate the prioritization of this issue based on community feedback.

[ghost]

@rittneje thank you for describing the issue so good. It matches our problem description too!

I would like to add our two use cases to this issue:

Use Case

We want to monitor LogGroups Usage by tagged projects.
We want to allocate LogGroups Costs (e.g. ingest, storage) to tagged projects.

[jglien]

This issue also applies to other resources, like RDS when you supply cloudwatchLogsExports. There is no clear workaround.

[github-actions]

This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue.

[whereisaaron]

Ran into this problem too. I need tags on the log group, but the CDK tag propagation isn't working. The CDK generated function already has a Custom "LogRetention" lambda which pre-creates the log group and applies the retention period. However that Lambda doesn't inherit the CDK tags nor apply them the log group it creates. It seems like CDK should create that log retention Lambda should have the CDK tags applied, and then the LogRetention lambda should copy the tags to the LogGroup it creates? The lambda could could propagate later tag changes.

"The LogGroup where the Lambda function's logs are made available.

If either logRetention is set or this property is called, a CloudFormation custom resource is added to the stack that pre-creates the log group as part of the stack deployment, if it already doesn't exist, and sets the correct log retention period (never expire, by default). Further, if the log group already exists and the logRetention is not set, the custom resource will reset the log retention to never expire even if it was configured with a different value."

BTW, It looks like the work to propagate tags to Log Group was done in this PR #26049 and approved, but then never merged.