(logs): delete associated log group when stack is deleted

[duarten]

When the log group of a Lambda function is created by the LogRetention custom resource, then those log groups linger after the stack has been deleted. It should be possible to configure the removal policy.

Use Case

Not having hundreds of dead log groups around, created for PR and test deployments.

Proposed Solution

This requires setting the deletionPolicy on the CfnResource, and implementing support for the "Delete" event type in the custom resource itself.

Other

N/A

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

---

This is a 🚀 Feature Request

[nija-at]

We could add this feature on the LogRetention construct and updating the handler with the Delete event.

Note that, the default must be to retain the logs.

[jagregory]

This would be a really useful feature. I'm creating a lot of temporary stacks for automated testing in CI, and it's leaving behind lots of log groups.

[wswoboda]

agreed, for the same reason as jagregory

[kornicameister]

I am tempted to give it a shot. Recently been playing with cdk internals to learn a bit more and this particular use case is close to my heart as well. Not promising anything, but will certainly play with it.

[FilipPyrek]

+1

Sorry, I'm new to CDK universe (but not to CloudFormation).

Does anybody know why does the log group needs to be created by custom resource? I've successfully accomplished this without need for any custom resources in CloudFromation/Serverless Framework in the past.

[mlafeldt]

Does anybody know why does the log group needs to be created by custom resource?

It creates the log group to be able to set the retention time. Otherwise, the log group will only be created once a Lambda logs something - with no expiry date set.

[FilipPyrek]

@mlafeldt you can create the log group inside CloudFormation and set it retention as parameter.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-loggroup.html#cfn-logs-loggroup-retentionindays

And then when the stack gets removed, it removes also the log group.

But it's true that I remember some case, when lambda executed during stack removal and in the meantime the log group was removed, but since there was a little delay before cloudwatch delivered the logs, it created a new log group with "Never expire" retention.

So maybe it's trying to address this issue. 🤷‍♂️

[mlafeldt]

@mlafeldt you can create the log group inside CloudFormation and set it retention as parameter.

Yes, that's what I do if I truly care about cleanup.

Most of the time I do not and LogRetention is just more convenient.

[mlafeldt]

PS: A friend of mine recently released https://github.com/itmettkeDE/lambda-delete-unnused-aws-loggroups, which cleans up Lambda and CodeBuild logs.

[shishkin]

We could add this feature on the LogRetention construct and updating the handler with the Delete event.

Yes, LogRetention needs a RemovalPolicy that when set to DESTROY would delete the log group.

[RomainMuller]

@shishkin but then what'll delete the LogRetention's backing lambda function's log group after it gets deleted? 🤓

[shishkin]

@shishkin but then what'll delete the LogRetention's backing lambda function's log group after it gets deleted? 🤓

If LogRetention lambda is a singleton resource its single log group is lesser evil than log groups created for each user lambda.

And if it is a singleton resource with a known log group name, maybe another custom resource could delete it as part of the stack deletion? And if that resource lacks CloudWatch permissions it would not leave behind any own logs 🤔

[greensmith]

And if it is a singleton resource with a known log group name, maybe another custom resource could delete it as part of the stack deletion? And if that resource lacks CloudWatch permissions it would not leave behind any own logs

Maybe I'm completely missing something here but I'm not sure why we should be so reliant on Cfn custom resources for everything. Why can we not handle this post-destroy?

Can we keep track of what Cfn has deployed and any "possible" children (i.e. Lambda LogGroups) then present information on orphaned resources that are not removed during Cfn delete?

This would be useful in CI to just say during post-build teardowns "here's a list of possibly orphaned resources - delete them"

[TheFlow0360]

Creating a log group with the same name is a workaround:

const nodejsFunction = new NodejsFunction(this, id, {
  ...
});
new logs.LogGroup(this, `LogGroupLambdaFunction ${id}`, {
  retention: logs.RetentionDays.ONE_WEEK,
  logGroupName: `/aws/lambda/${nodejsFunction.functionName}`,
  removalPolicy: RemovalPolicy.DESTROY,
});

This, however, breaks other integrations with the custom resource like subscriptions. So a way to directly configure the RemovalPolicy would be better.

[greensmith]

Another alternative is changing policies on the role to deny log access , to stop them being created in the first place.
e.g. for BucketDeployment, if we're deploying/destroying multiple dev branches i'd rather not have to worry about going in and tidying up after a destroy than having 99/100 logs saying the zip contents were extracted successfully.

const BucketDeploymentHandler = this.bucketDeployment.node.findChild('CustomResourceHandler') as SingletonFunction;
        BucketDeploymentHandler.addToRolePolicy(new PolicyStatement({
            actions:['logs:*'],
            resources:['*'],
            effect: Effect.DENY
       })
)

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[albertodiazdorado]

Bump

This is a very important feature IMO

[gshpychka]

Bump

This is a very important feature IMO

It has been implemented.

[albertodiazdorado]

Oh that's great. Thanks for letting me know @gshpychka !