AWS Lambda MicroVMs sind ein neues Serverless-Primitiv, das nach AWS' eigener Darstellung dafür gebaut wurde, von Benutzern oder KI generierten Code in isolierten, zustandsbehafteten Umgebungen auszuführen. Das zweite Wort ist das, worauf es ankommt. Bei dem Launch geht es nicht wirklich um Funktionen. Es geht darum, einem KI-Agent einen sicheren Ort zu geben, um den Code auszuführen, den er gerade geschrieben hat. Und die Tatsache, dass AWS mit "Benutzern oder KI" voranging, sagt dir, für wen das gedacht ist.

Wenn du Agents baust, bist du bereits gegen diese Wand gelaufen. Das Modell schreibt Code, und dann musst du ihn irgendwo ausführen. Nicht vertrauenswürdigen, modellgenerierten Code auf deiner eigenen Infrastruktur auszuführen ist der Teil, den alle unterschätzen, und genau das ist der Teil, den MicroVMs dir abnehmen sollen.

Das Sandbox-Problem, das Agents tatsächlich haben

Ein fähiger Agent antwortet nicht einfach nur. Er schreibt ein Skript, führt es aus, liest das Ergebnis und iteriert. Code-Interpreter, Datenanalyse-Agents und autonome Coding-Tools stehen und fallen alle mit einer Frage: wo läuft dieser Code?

Die naiven Antworten sind alle schlecht. Führe ihn in deinem Anwendungsprozess aus, und eine einzige feindselige oder fehlerhafte Generierung kann den Host lahmlegen oder die Daten eines anderen Benutzers lesen. Führe ihn in einem geteilten Container aus, und du bist einen Kernel-Exploit von einem Cross-Tenant-Breach entfernt, weil Container sich einen Kernel teilen. Baue deine eigene VM-Flotte, und du hast dich gerade dazu verpflichtet, die schwierigste und am wenigsten differenzierende Infrastruktur in deinem Stack zu betreiben. Modellgenerierter Code ist per Definition nicht vertrauenswürdiger Code. Er braucht eine echte Isolationsgrenze, keine höfliche.

Warum MicroVMs zur agentischen Form passen

Lambda MicroVMs decken sich auf drei Achsen damit, wie Agents sich tatsächlich verhalten.

Isolation, die gegen feindselige Ausgaben standhält

Jede Session läuft in ihrer eigenen Firecracker MicroVM: kein geteilter Kernel, keine geteilten Ressourcen, kein Pfad von einer Umgebung zur anderen oder zum Host. Wenn dein Agent Code ausführt, den ein Sprachmodell aus dem Prompt eines Benutzers erzeugt hat, ist das die Grenze, die du zwischen "der Agent hat etwas Seltsames gemacht" und "der Agent hat die Plattform kompromittiert" haben willst. Ein per prompt injection manipulierter Agent, der sich entscheidet, Daten zu exfiltrieren oder zu zerstören, bleibt auf eine wegwerfbare VM beschränkt.

Zustand, der zu einer mehrstufigen Aufgabe passt

Agent-Arbeit ist selten ein einziger Schuss. Er installiert ein Paket, lädt einen Datensatz, schreibt Zwischendateien und kommt drei Schritte später wieder darauf zurück. Eine MicroVM bewahrt Speicher, Festplatte und laufende Prozesse über die Session hinweg und kann mit intaktem Zustand während der langen Pausen suspendieren, während das Modell nachdenkt oder der Benutzer kurz weg ist, um dann nahezu sofort fortzusetzen. Geladene Modelle und Arbeitsdateisätze sind einfach immer noch da. Das passt weitaus besser, als bei jedem Tool-Aufruf einen frischen Container neu zu starten.

Schnell genug starten, um sich interaktiv anzufühlen

Weil jede MicroVM aus einem vorinitialisierten Firecracker-Snapshot fortsetzt, statt kalt zu booten, kommt selbst eine Session von mehreren Gigabyte schnell zurück. Für einen interaktiven Agent, bei dem ein Mensch zusieht, wie der Cursor blinkt, ist der Unterschied zwischen einem Snapshot-Resume und einem kalten Container-Start der Unterschied zwischen nutzbar und aufgegeben. Sessions können bis zu 8 Stunden laufen, was eine lange Analyse oder eine ausgedehnte Coding-Session bequem abdeckt.

AWS baut die gesamte Agent-Schleife, nicht nur die Laufzeit

Der MicroVM-Launch kam nicht allein. AWS hat außerdem einen Agent-Setup-Guide ausgeliefert, der Coding-Agents, Claude Code, Codex, Cursor, Kiro, Copilot, Windsurf, OpenCode, über Plugins, Agent-Skills und einen MCP Server in die serverlose Entwicklung einbindet. Lies die beiden zusammen, und die Strategie ist klar: Agents helfen dir, die serverlose Anwendung zu bauen, und MicroVMs sind der Ort, an dem der von diesen Agents generierte Code sicher laufen kann. AWS versucht, beide Enden der Schleife zu besitzen: den Agent, der schreibt, und die Sandbox, die ausführt.

Was es nicht löst

Isolation ist eine Grenze, kein Gehirn. Eine MicroVM hindert modellgenerierten Code daran, aus seiner Sandbox auszubrechen. Sie tut nichts, um den Agent davon abzuhalten, etwas Dummes, aber Erlaubtes innerhalb der Box zu tun, oder davon, Anmeldedaten zu erhalten, die den Wirkungsradius über sie hinaus ausdehnen. Wenn du echte Secrets einbindest oder der Sandbox eine breite IAM-Rolle gibst, ist die VM-Grenze irrelevant für den Schaden, den ein injizierter Prompt über legitime API-Aufrufe anrichten kann. Begrenze, was die Sandbox erreichen kann, so eng, wie du sie isolierst. Die Laufzeit ist die einfache Hälfte; Least-Privilege für den Agent liegt immer noch bei dir.

Das Fazit

Während des größten Teils des agentischen Booms wurde die Laufzeitfrage, wo der generierte Code tatsächlich ausgeführt wird, mit Klebeband beantwortet: ein Container hier, ein abgeschotteter Prozess dort, ein selbstgebauter VM-Pool für die Teams, die es sich leisten konnten. Lambda MicroVMs verwandeln das in ein verwaltetes Primitiv mit Isolation auf VM-Ebene, zustandsbehafteten Sessions und einem Resume in Snapshot-Geschwindigkeit, bereitgestellt als API-Aufruf. Es macht deinen Agent nicht schlauer oder sicherer in dem, was er entscheidet zu tun. Es gibt dem Code, den er schreibt, einen Ort zum Laufen, der nicht alles um ihn herum lahmlegen kann, und für Produktions-Agents war das das fehlende Stück.

Lies das als Nächstes

Für die Serverless- und Infrastruktur-Aufschlüsselung desselben Launches, den Lebenszyklus, die CLI und wo es im Vergleich zu regulärem Lambda passt, siehe die Field Notes auf ercan.cloud. Für Beratung zu KI, AWS und Plattformarbeit, oder einfach nur, um Hallo zu sagen, beginne bei ercanermis.com.

Referenzen