Lifecycle policies for Lambda Resources
- Dominant language
- No language data
- Stars
- 196
- Forks
- 5
- PR merge metrics
- No merged PRs in 30d
Description
**Note**
> * Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
> * Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do * not help prioritize the request
> If you are interested in providing additional feedback, please leave a comment
**Description**
We are exploring supporting lifecycle policies for versioned Lambda resources. With this feature, customers could delete multiple versions at once via a retention policy. We are exploring "max versions", "last invoked", and other qualifiers to automatically delete versions that do not match the policy when you create a new version or update a resource.
**Additional context**
1. What types of actions would you want to take, for example, label a function as deprecated, delete a layer version, block invokes, etc.?
2. What types of timestamp based rules would you write, for example, 1 year after function version create date do x.
3. Are there any other attributes you would want to reference in your policy?
4. Do you need to write policies to delete resources based on the status of other resources, for example, delete all function versions that reference outdated runtimes?
5. How would you want to handle dependencies for example, would you want to automatically delete function versions associated with a specific layer version?
Contributor guide
Assessment
This issue has not been assessed yet.