Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

[Lambda MicroVMs] Keep only the newest N MicroVM image versions

Aberta
  • Algo errado?
#120 3 comentários 2 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
30/100
Tipo de issue
Funcionalidade
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
aws
Domínio
cloud

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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 INACTIVE without 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.

Linguagem predominante
Sem dados de linguagem
Estrelas
199
Forks
5
Nenhum PR com merge em 30d

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de aws/aws-lambda-roadmap

Todas as issues de aws/aws-lambda-roadmap

Issues semelhantes

Mais issues de Cloud

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.