Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#120 3 Kommentare 2 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
30/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
aws
Bereich
cloud

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Keine Sprachdaten
Sterne
199
Forks
5
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus aws/aws-lambda-roadmap

Alle Issues in aws/aws-lambda-roadmap

Ähnliche Issues

Weitere Issues zu Cloud

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.