[Lambda MicroVMs] Keep only the newest N MicroVM image versions
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 30/100
- Issue 类型
- 功能
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- aws
- 领域
- cloud
调研方向
The request concerns CreateMicrovmImage, UpdateMicrovmImage, and version deletion for AWS Lambda MicroVMs; no repository files or tests are named. Start by reading those API operations and the image version lifecycle documentation, then identify how successful builds, active versions, and versions used by MicroVMs are tracked. Done means a retention setting prunes eligible older versions while preserving all versions the issue says must be kept.
由索引模型根据 Issue 内容生成。
描述
Community 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 working on this issue or have submitted a pull request, please leave a comment
Tell us about your request
Add a retention setting on a MicroVM image that keeps only the newest N versions and deletes the rest.
For example, maximumImageVersions (or similar) on CreateMicrovmImage and UpdateMicrovmImage, defaulting to the current behavior when unset. After a successful build, Lambda would delete older versions beyond that count. The live version, a version that a pending, running, suspending, or suspended MicroVM still uses, and a version that is still building would be kept even if that exceeds N.
Which service(s) is this request for?
AWS Lambda MicroVMs (lambda-microvms). Image versions, not MicroVM run duration.
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
We publish a new version of one MicroVM image on every application deploy. Each UpdateMicrovmImage creates a version, and an image is capped at 50 versions (Versions per MicroVM image). Once that quota is reached, the next update fails with ServiceQuotaExceededException ("has reached the maximum number of versions allowed") and deploys stop.
There is no retention, lifecycle, or "keep the newest N" parameter on create or update. UpdateMicrovmImageVersion with status INACTIVE disables a version but does not free a quota slot. The only way to make room is DeleteMicrovmImageVersion for each old version. Raising the quota only delays the same failure.
The impact is a broken deploy pipeline: the image cannot be updated until something outside the service deletes old versions. Classic Lambda function versions have the same gap, which is why deploy tools prune them. MicroVM images need this more, because the default cap is 50 and a normal deploy cadence hits it.
Are you currently working around this issue?
Yes. A scheduled job lists versions, keeps the newest 10 plus any version that is still building or still in use, and calls DeleteMicrovmImageVersion on the rest. That job has to exist, be permitted (lambda:ListMicrovmImageVersions, lambda:DeleteMicrovmImageVersion, lambda:GetMicrovmImage), and run often enough that deploys between runs cannot fill the remaining slots. We would rather set the retention on the image and have Lambda enforce it when a new version succeeds.
Additional context
Relevant today:
- Quota: Versions per MicroVM image is 50 by default.
- Delete is explicit:
DeleteMicrovmImageVersion. - Inactive is not deletion. The image docs say a version can be set
INACTIVEwithout deleting it. - Best practices already say to delete image versions you no longer need, but the service does not do it.
A useful shape would match what deploy tools already do for function versions: keep the newest N successful versions, always keep the latest active version and any version a MicroVM can still resume from, and delete failed versions without counting them toward N.
Attachments
None.
- 主要语言
- 没有语言数据
- 星标
- 199
- 派生
- 5
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
aws/aws-lambda-roadmap 的其他 Issue
-
难度 5/5 一周以上 新手友好度 25/100
aws/aws-lambda-roadmap#123 ·
-
Feature-Lambda SnapStart support for larger ephemeral storage可能已有人在做 @prerna-aws 于 3 天前认领。 未关闭
aws/aws-lambda-roadmap#122 · 已指派 1 人 ·
-
Feature- Lambda Dev Sandbox to accelerate local development可能已有人在做 @prerna-aws 于 3 天前认领。 未关闭Lambda/Developer Experience
aws/aws-lambda-roadmap#121 · 已指派 1 人 ·
-
难度 5/5 一周以上 新手友好度 25/100
aws/aws-lambda-roadmap#119 · 45 个 reaction ·
-
Lambda/Developer Experience Lambda/Web Functions
难度 5/5 一周以上 新手友好度 6/100
aws/aws-lambda-roadmap#118 · 3 条评论 · 2 个 reaction ·
查看 aws/aws-lambda-roadmap 的全部 Issue
相似的 Issue
-
needs-triage
难度 2/5 1-3 小时 新手友好度 82/100
kubernetes/cloud-provider-aws#1517 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
aws/context-ontology-accelerator#343 ·
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 78/100
-
难度 2/5 1-3 小时 新手友好度 78/100
afreidah/s3-orchestrator#1824 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
apache/cloudstack#14530 ·
维护者通常 1 天内回复