Add boolean option to aws.lambda delete action to allow retaining of the #Latest version for c7n cleanup

Is your feature request related to a problem? Please describe. We recently ran into an issue at the company I work for where a couple hundred of our AWS accounts reached the soft limit on Lambda Storage size which then caused our new policies to fail deployment and our customers got a little upset as they couldn’t deploy any lambdas in their accounts either. Upon investigation we found that our custodian lambda functions had numerous versions, some having as few a 6 versions but some having 600+ versions. I wrote a custom script to go out and delete all the custodian lambda versions that were not the #Latest version and our lambda storage space went from 100% of the 75 GB down to 0.1% of the 75 GB! While this will not apply to everyone as it depends on how you deploy your lambda policies and the frequency at which you do so. Just thought it was something to be aware of when you are deploying lots and lots of lambda based policies.

Describe the solution you’d like Maybe having an option within aws.lambda for the delete action to delete all non-current versions of lambdas would be helpful.

Something like this:
- name: cleanup-old-custodian-lambda-versions
  resource: lambda
  filters:
        - type: value
          key: FunctionName
          op: regex
          value: ^(custodian-?)\w+
  actions:
        - type: delete
          keep-latest: true

Describe alternatives you’ve considered I wrote a script to achieve this but ultimately having this as an option via policy would be more elegant and easier to manage

Additional context Thanks! 😃

[tjstansell]

That seems like an lot of overhead. I’d hope we could have an option to avoid all of that for folks that know there are no dependencies on old versions or don’t care.

That said, we should be able to use the function policy to help us determine what other service to check rather than having to check all of them.

Looking at other cleanup scripts out there, most of them only check for aliases if they check anything at all.

The console seems fairly quick to show you your triggers, but that’s also just a single lambda. If you’re cleaning up hundreds I’d be a bit concerned by the api calls. It’s a bit like invalid-asg with all the overhead to confirm it’s safe. Of course, then there’s the cross-account access. It’s unlikely we would be able to tell in those cases if they target a version.

I’d argue that just checking for references by alias is a good start. And maybe have a way for folks to skip all safety checks.

If we go the route of having lambda-version be its own resource, maybe we just have a has-alias filter or maybe an unused filter that folks can choose to do the exhaustive search.

[kapilt]

@JohnHillegass this isn’t really specific to custodian, its a general problem with lambdas, hence the analysis on how to solve safely with a resource action.

@tjstansell I’m hopeful the api volume won’t be too bad for discovery, we can parse the lambda policy (version independent) to identify a relevant set of services for a given set of lambda functions, in some cases the policy statements have resource identifiers. The structuring of the solution here seems more appropriate to function then version, since we have to consider the set and aliases which span across versions, as well as the use of function policy which is independent of version, plus the complication of being able to express succintly for version. internally this action may use a function version resource, tbd.