Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#120 3 commenti 2 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
aws
Ambito
cloud

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Nessun dato sulla lingua
Stelle
199
Fork
5
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di aws/aws-lambda-roadmap

Tutte le issue di aws/aws-lambda-roadmap

Issue simili

Altre issue su Cloud

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.