AWS Lambda MicroVMs: Serverless bekommt eine zustandsbehaftete, isolierte Sandbox

AWS Lambda MicroVMs sind ein neues serverless Compute-Primitiv, das Ihnen Isolation auf Ebene einer virtuellen Maschine, nahezu sofortigen Start aus einem snapshot und zustandsbehaftete Ausführung gibt, die Sie suspendieren und wieder aufnehmen können. Es läuft auf Firecracker, derselben leichtgewichtigen Virtualisierung, die bereits mehr als 15 Billionen Lambda-Aufrufe pro Monat trägt. Die Kurzfassung: Lambda hat gerade die Fähigkeit dazubekommen, jeder Sitzung ihre eigene dedizierte, isolierte, langlebige Sandbox zu übergeben, und das, ohne dass Sie selbst irgendeine Virtualisierung verwalten müssen.

Wenn Sie jemals versucht haben, Code sicher auszuführen, den Ihre eigene Anwendung nicht geschrieben hat, also mandantenübergreifende Codeausführung, interaktive Notebooks, Schwachstellen-Scanner, dann wissen Sie bereits, warum das wichtig ist. Die ehrliche Antwort lautete bis jetzt: "Starte Container oder VMs und baue die Orchestrierung, Isolation und Lifecycle-Verkabelung selbst." MicroVMs verdichten das auf einen API-Aufruf.

Was tatsächlich neu ist

Reguläre Lambda-Funktionen sind zustandslos, kurzlebig und ereignisgesteuert. Dafür sind sie hervorragend. Sie sind auch das falsche Werkzeug, wenn Sie eine Sitzung brauchen, die minuten- oder stundenlang lebt, State im Arbeitsspeicher hält und nicht vertrauenswürdigen Code auf Kernel-Ebene isoliert. MicroVMs sind ein anderes Primitiv innerhalb desselben Dienstes, das genau auf diese Lücke zielt. AWS rahmt es als drei Fähigkeiten ein, die bis heute kein einzelner AWS-Compute-Dienst zusammen bot.

1. Isolation auf VM-Ebene

Jede Sitzung läuft in ihrer eigenen dedizierten MicroVM, ohne gemeinsam genutzten Kernel und ohne gemeinsam genutzte Ressourcen zwischen Nutzern. Das ist die Firecracker-Garantie: nicht vertrauenswürdiger Code eines Mandanten ist auf seine eigene Umgebung beschränkt, ohne Pfad zu anderen Umgebungen oder zum Host. Container teilen sich einen Kernel; eine MicroVM tut das nicht. Für das Ausführen von Code, den Sie nicht geschrieben haben, ist genau diese Grenze der ganze Punkt.

2. Snapshot-schneller Start und Resume

Das Modell ist Image-dann-Launch. Sie bauen ein MicroVM-Image aus einem Dockerfile plus einem Code-Artefakt in Amazon S3. Lambda führt das Dockerfile aus, initialisiert Ihre Anwendung und nimmt einen Firecracker-snapshot des laufenden Speicher- und Festplattenzustands. Jede MicroVM, die aus diesem Image gestartet wird, nimmt vom vorinitialisierten snapshot wieder auf, statt kalt zu booten. Selbst eine interaktive Sitzung von mehreren Gigabyte kommt schnell genug zurück, um sich live anzufühlen. Das ist die SnapStart-Idee zu ihrem logischen Ende geführt: Sie starten keinen Prozess, Sie stellen einen laufenden wieder her.

3. Zustandsbehaftete, suspendierbare Ausführung

Eine laufende MicroVM behält ihren Speicher, ihre Festplatte und ihre Prozesse über die gesamte Sitzung hinweg. Wenn sie im Leerlauf ist, kann sie mit intaktem State suspendiert und dann wieder aufgenommen werden, wenn der Traffic zurückkehrt. Installierte Pakete, geladene Daten und Arbeitsdateien sind alle noch da. MicroVMs unterstützen bis zu 8 Stunden Gesamtlaufzeit und suspendieren automatisch nach einem konfigurierbaren Leerlauffenster. Das ist der Teil, der die alte Annahme von zustandslosem Serverless aufbricht, und zwar im positiven Sinne.

Wie sich der Betrieb anfühlt

Zwei CLI-Aufrufe tragen den Großteil des Workflows. Zuerst das Image bauen:

aws lambda-microvms create-microvm-image \
  --code-artifact uri=<path/to/s3/artifact.zip> \
  --name my-sandbox \
  --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \
  --build-role-arn <build role ARN>

Build-Logs werden zu CloudWatch unter /aws/lambda/microvms/<image-name> gestreamt, und das fertige Image taucht mit seinem eigenen ARN und seiner Version auf. Dann starten Sie eine MicroVM daraus:

aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-sandbox \
  --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \
  --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'

Lambda gibt eine eindeutige MicroVM-ID und eine dedizierte Endpunkt-URL zurück, wobei die Anwendung bereits läuft, weil sie vom snapshot wieder aufgenommen hat. Kein Networking zu konfigurieren. In der idle-policy sitzt die Lifecycle-Steuerung: wie lange im Leerlauf bleiben, bevor suspendiert wird, wie lange suspendiert bleiben, bevor terminiert wird, und ob beim nächsten Request automatisch wieder aufgenommen wird.

Wo es passt und wo nicht

Greifen Sie zu MicroVMs, wenn	Bleiben Sie bei regulärem Lambda, wenn
Sie nicht vertrauenswürdigen oder von Nutzern bereitgestellten Code ausführen und Isolation auf Kernel-Ebene brauchen	Ihr Code vertrauenswürdig ist und die Arbeit eine kurze, zustandslose Transformation ist
Eine Sitzung State im Speicher über Minuten oder Stunden hinweg halten muss	Jeder Aufruf unabhängig ist und in Sekunden fertig wird
Sie pro Nutzer dedizierte Umgebungen wollen, ohne die Flotte selbst zu betreiben	Es Ihnen recht ist, eine verwaltete Ausführungsumgebung zu teilen
Leerlaufphasen normal sind und Sie Suspend-Resume wollen, statt fürs Leerlaufen zu zahlen	Der Traffic gleichmäßig ist und Request-Response die gesamte Form darstellt

MicroVMs sind kein Ersatz für Funktionen, und sie sind kein billiger Weg, um einen 24/7-Server zu betreiben. Die 8-Stunden-Obergrenze und das Suspend-Resume-Modell sind für Sitzungen gebaut: eine Coding-Sandbox, die ein Nutzer öffnet und liegen lässt, ein Scan, der zehn Minuten läuft, ein Analyse-Job, der zwei Stunden rödelt und dann still wird. Wenn Ihre Last ein durchgehend ausgelasteter, langlebiger Dienst ist, dann ist das immer noch ECS- oder EC2-Terrain.

Der snapshot-Vorbehalt, den man kennen sollte

Weil jede MicroVM von einem vorinitialisierten snapshot wieder aufnimmt, kann alles, was Ihre App während der Initialisierung tut und dabei Frische voraussetzt, Sie überraschen. Eindeutige IDs, die beim Start generiert werden, Netzwerkverbindungen, die beim Boot geöffnet werden, Random Seeds oder einmalig geladene flüchtige Daten können allesamt in den snapshot eingefroren und über Launches hinweg wiederverwendet werden. Das ist dieselbe Art von Fallstrick, die SnapStart-Nutzer bereits kennen: Wenn etwas pro Sitzung eindeutig oder frisch sein muss, generieren Sie es nach dem Resume, nicht während der Initialisierung. AWS stellt dafür Hooks bereit, und Sie werden sie für alles Verbindungsorientierte oder Sicherheitsrelevante wollen.

Das Fazit

Lambda MicroVMs sind das bisher deutlichste Signal, dass Serverless aufhört, nur zustandslos und kurzlebig zu sein. Sie bekommen jetzt eine verwaltete Firecracker-Sandbox mit echter Isolation, snapshot-schnellen Starts und Suspend-Resume-State, bereitgestellt als zwei API-Aufrufe und eine idle-policy. Für alle, die mandantenübergreifende Codeausführung bauen, nimmt das den schwierigsten, am wenigsten differenzierenden Teil der Arbeit weg: die Isolation und die Lifecycle-Verkabelung. Bauen Sie das Produkt, lassen Sie Lambda die MicroVM-Flotte betreiben.

Lies das als Nächstes

AWS Monthly (Nov '25): The Stateful Serverless Revolution, für die Trendlinie, auf der MicroVMs liegen.
Securing Docker Containers, dazu, warum ein gemeinsam genutzter Kernel die Grenze ist, die MicroVMs entfernen sollen.

Für den KI- und Agenten-Blickwinkel auf denselben Launch, also warum MicroVMs für das Ausführen von KI-generiertem Code gebaut sind, lies die Feldnotizen auf ercan.ai. Für Beratung zu AWS, Serverless und Plattformarbeit, oder einfach nur, um Hallo zu sagen, beginne bei ercanermis.com.