AWS Lambda Orphaned Log Groups: Delete or Retain?

DEV Community

Deleting a Lambda leaves its log group behind. What do you do with the ones nobody owns?

This week I went through an AWS account where Lambda functions come and go every sprint. The functions were gone. Their log groups were not. CloudWatch creates /aws/lambda/ on the first invoke with retention set to "Never expire", and deleting the function does not touch it. The Lambda docs say it in one sentence; nobody reads that sentence until the bill does. The count was not dramatic in dollars. A few hundred GB of logs nobody will ever open, at the storage rate that is a few dollars a month. The part that bothered me was the ownership. The team that wrote those functions moved on, the Terraform that created them never declared the log group, and the destroy that removed the function left the group with no stack, no tag and no owner. It sits in the list between groups that matter. AWS added account-level retention policies this month, so now one put-account-policy with a /aws/lambda prefix puts an expiry on all of them, existing ones included. That stops the growth. It does not delete the group, and it does not tell you which ones still have a function behind them. My current answer is a cross: list the groups with no retention, list the functions that exist, and treat the difference as orphans to delete after a snapshot of the names. It works, and it is a script I have to remember to run. So the question for people running more accounts than I do: do you delete orphaned log groups at all, or do you set retention and let them fade to zero bytes? And if you delete, what stops you from deleting the one that a compliance rule wanted kept?

Powered by Readybot.io