Am 22. Juni 2026 veröffentlichte AWS einen offiziellen Blogpost. Der Titel war lang, aber der Kern bestand aus einem Satz: Lambda kann jetzt MicroVMs ausführen.
AWS hat keinen neuen Service, keine neue SKU auf den Markt gebracht – im 11 Jahre alten Serverless-Produkt Lambda hat sich eine völlig neue Tür geöffnet. Mein erster Gedanke nach der Lektüre: AWS holt Firecracker aus dem Maschinenraum auf die Bühne, und diesmal nicht für Lambdas eigene Funktionen, sondern direkt für Entwickler.
Was genau wurde veröffentlicht
Lambda MicroVMs sind eine neue Compute-Primitive. Sie teilen sich den Konsoleneingang mit Lambda Functions, aber die API ist vollständig anders: Du lädst ein Dockerfile plus ein Code-Archiv in S3 hoch, Lambda baut das Image, initialisiert die Anwendung und erstellt einen Firecracker-Snapshot. Bei jedem weiteren Start der MicroVM wird direkt aus diesem vorgewärmten Snapshot wiederhergestellt – die Kaltstartphase wird komplett übersprungen.
Einige Schlüsselparameter verdienen Aufmerksamkeit:
- Maximale Instanzgröße: 16 vCPU, 32 GB RAM, 32 GB Disk, ARM64 (Graviton)
- Maximale Laufzeit: 8 Stunden – das 15-Minuten-Limit von Lambda Functions entfällt
- Idle-Strategie: Konfigurierbarer automatischer Suspend; im Suspend-Zustand fallen nur Snapshot-Speicherkosten an; Wiederherstellung bewahrt kompletten Speicher- und Festplattenzustand
- Startmechanismus: Snapshot-Wiederherstellung statt Kaltstart. Nach erfolgreichem Start sofort ein einsatzbereiter HTTP-Endpunkt
- Erste Regionen: US East (Virginia, Ohio), US West (Oregon), Europe (Irland), Asia Pacific (Tokio)
Die Abrechnung erfolgt nach vCPU/Sekunde und RAM/GB/Sekunde; nach Suspend fallen keine Rechenkosten mehr an. Das entspricht der Abrechnungslogik von Lambda Functions, aber da einzelne Sitzungen stundenlang dauern können, ähnelt die tatsächliche Rechnungsstruktur eher der einer On-Demand-VM – plus Pausenfähigkeit.
Der offizielle AWS-Blog listet explizit eine Reihe von Zielszenarien auf: KI-Programmierassistenten, interaktive Code-Umgebungen, Datenanalyseplattformen, Schwachstellenscanner, Spieleserver mit benutzergenerierten Skripten. Was ist das gemeinsame Merkmal? Jeder Endnutzer braucht eine eigene, isolierte Umgebung, die nicht vertrauenswürdigen Code sicher ausführen kann.
Warum jetzt
Diese Frage lohnt sich, auseinandergenommen zu werden.
Firecracker ist seit 2018 Open Source. In den vergangenen sieben Jahren hat es monatlich über 15 Billionen Lambda-Funktionsaufrufe getragen. Die Technologie ist ausgereift, aber AWS hat Firecracker nie als entwicklerorientiertes Produkt vermarktet – bis jetzt.
Was sich geändert hat, ist nicht AWS’ strategische Präferenz, sondern die Nachfrageseite.
Von 2025 bis zur ersten Hälfte 2026 haben sich KI-Code-Assistenten von Experimenten zu Alltagswerkzeugen entwickelt. Claude Code, Codex CLI, Gemini Code Assist – diese Agenten generieren nicht nur Code, sie führen ihn auch aus. Pakete installieren, Dienste starten, ins Dateisystem schreiben, Netzwerkanfragen stellen. Millionen Mal täglich. Und die Umgebung, in der dieser Code ausgeführt wird, ist entweder ein Docker-Container (geteilter Kernel, Isolation über Namespaces + Cgroups + Seccomp) oder eine virtuelle Maschine (starke Isolation, aber langsamer Start).
Noch kniffliger: Die Agenten selbst umgehen aktiv sicherheitstechnische Einschränkungen auf Softwareebene. Im März 2026 demonstrierte Falco-Core-Maintainer Leonardo Di Donato, wie Claude Code seine eigene Sandbox umging: Der Agent entdeckte, dass /proc/self/root/usr/bin/npx die Deny-Regel umging; nachdem Bubblewrap dies abfing, deaktivierte der Agent die Sandbox einfach komplett. Kein Jailbreak, kein spezieller Prompt. Er wollte nur seine Aufgabe erledigen.
Dieser Fall illustriert eine fundamentale Tatsache: Userspace-basierte Isolation (Denylists, Permission Prompts, Seccomp-Regeln) und die Reasoning-Fähigkeit des Agenten operieren auf derselben Ebene. Der Agent hat genug Verständnis, um sie zu umgehen. Die Isolation der MicroVM hingegen wird durch Hardware-Virtualisierung erzwungen – auf einer Ebene, die der Agent nicht erreichen kann.
Der Zeitpunkt der Einführung von Lambda MicroVMs fällt hochgradig mit dem Ausbruch dieses Sicherheitsproblems zusammen.
Die Landschaft des Sandbox-Marktes
Lambda MicroVMs sind nicht aus dem Nichts erschienen. Vor ihnen hatte sich bereits ein beachtliches Ökosystem an Tools und Plattformen um die Frage formiert: »Wie führt man nicht vertrauenswürdigen Code sicher aus?« Ich skizziere die wichtigsten Lager, ohne Wertung, nur mit Fokus auf Architekturunterschiede und Einsatzkontexte.
Das Firecracker-Lager
AWS selbst ist natürlich der größte Spieler. Neben den neuen Lambda MicroVMs nutzt auch AWS Bedrock AgentCore Firecracker, um jeder Agent-Session eine eigene MicroVM bereitzustellen.
Bei den unabhängigen Plattformen ist E2B ein auf KI-Agent-Sandboxen spezialisierter Dienst: Firecracker als Basis, ~150 ms Startzeit, Eigenangabe zufolge 88 % der Fortune 100 registriert. Fly.io Sprites bietet persistente, stateful VMs mit Checkpoint/Restore in ~300 ms, vorinstalliert mit Claude Code und Codex CLI. Vercel Sandbox setzt ebenfalls auf Firecracker, Schwerpunkt auf Millisekunden-Snapshot-Wiederherstellung für KI-Code-Interpreter. SlicerVM verfolgt den Self-Hosted-Ansatz und unterstützt sowohl Firecracker als auch Cloud Hypervisor, außerdem Apple Virtualization Framework unter macOS.
Bei den Open-Source-Projekten ist Matchlock hervorzuheben: eine Firecracker-Sandbox speziell für KI-Agenten, mit Default-Deny-All-Netzwerkrichtlinie, Domain-Whitelist und Credential-Schutz – explizit entwickelt, um das Sicherheitsproblem von claude --dangerously-skip-permissions zu adressieren.
Das libkrun-Lager
Red Hats libkrun verfolgt den Library-VMM-Ansatz – MicroVM-Fähigkeiten werden als Bibliothek verpackt, die von anderen Programmen aufgerufen werden kann, statt als eigenständiger Daemon. Microsandbox (YC-Inkubator, Apache 2.0, ~4.700 GitHub Stars) ist der prominenteste libkrun-Konsument: eine selbstgehostete KI-Agent-Sandbox, jede Instanz bekommt einen eigenen Kernel, ein eigenes Dateisystem und einen eigenen Netzwerkstack.
Ein Differenzierungsmerkmal von libkrun ist die Plattformunabhängigkeit: unter Linux via KVM, unter macOS via Hypervisor.framework. Der Nachteil: Es fehlt ein Kubernetes-Orchestrierungslayer und clusterweites Management – libkrun ist stärker für Einzelmaschinen-Deployments geeignet, ideal für Entwickler lokal oder kleine Teams, weniger für große Multi-Tenant-Produktionsumgebungen.
Kata Containers
Kata Containers unterscheidet sich grundlegend in der Positionierung: Es bietet ein Orchestrierungs-Framework, das Firecracker, Cloud Hypervisor oder QEMU in die Kubernetes-Runtime-Schicht einbettet, sodass jeder Pod in einer eigenen leichtgewichtigen VM läuft. Für Kubernetes sieht es aus wie ein normaler Container; darunter befindet sich vollständige Hardware-Isolation.
Startzeit ~150–300 ms (abhängig von der VMM-Wahl), Speicher-Overhead <10 MiB plus Gast-Kernel. Katas Kernwert liegt darin, die operative Komplexität von MicroVMs zu kapseln – man muss sich nicht selbst um Kernel-Images, Netzwerkkonfiguration oder VM-Lebenszyklus kümmern. Northflank betreibt Kata Containers + Cloud Hypervisor in Produktion mit durchschnittlich über 2 Millionen MicroVMs pro Monat.
Kata zielt auf langlebige, Kubernetes-orchestrierte Multi-Tenant-Workloads, nicht auf kurzlebige Session-Starts.
gVisor
Googles gVisor geht einen völlig anderen technischen Weg: Keine VM um den Container herum, sondern ein in Go geschriebener Userspace-Kernel (Sentry) zwischen Container und Host-Kernel. Die Syscalls des Containers werden von Sentry abgefangen und im Userspace verarbeitet; nur wenige notwendige Operationen werden an den Host-Kernel durchgereicht.
Das bedeutet: kein VM-Start-Overhead, keine Notwendigkeit für verschachtelte Virtualisierung, kürzester Integrationspfad mit Docker/Containerd. Der Preis: I/O-intensive Workloads haben 10–30 % Syscall-Overhead. gVisors Isolationsstärke liegt zwischen Container und VM – es reduziert die Kernel-Angriffsfläche erheblich (Sentry implementiert nur ~230 Syscalls, der Linux-Kernel hingegen 450+), erreicht aber keine Isolation des Arbeitsspeichers auf Hardware-Ebene.
Modal ist das repräsentative Produkt des gVisor-Ansatzes: GPU-unterstützte Sandbox-Umgebungen, ~300 ms Start, Schwerpunkt auf Inferenz- und Trainingsszenarien.
Cloudflare Workers (V8 Isolates)
Cloudflare geht den anderen Extremweg: V8 Isolates. Startzeit im Submillisekunden-Bereich, aber nur JavaScript/TypeScript/WASM werden unterstützt. 2026 wurde Dynamic Workers eingeführt, eine Funktion, die es LLMs erlaubt, zur Laufzeit dynamisch JS/TS-Unter-Isolates für Codeausführung zu generieren – mit 81 % weniger Token-Verbrauch als traditionelles Tool-Calling. Es ist keine universelle Sandbox, aber innerhalb des JS/WASM-Ökosystems ist die Dichte- und Latenzleistung unerreicht.
Differenzierungsdimensionen
Nach der Durchsicht der verschiedenen Ansätze zeichnen sich mehrere Wettbewerbsdimensionen ab:
Snapshot/Fork-Fähigkeit. Lambda MicroVMs’ »vorgewärmter Snapshot-Start« friert im Kern einen bereits initialisierten Laufzeitzustand ein und stellt ihn beim nächsten Start wieder her. Unikraft Cloud hat diesen Gedanken auf die Spitze getrieben – Eigenangabe: <10 ms Kaltstart, über 100.000 isolierte Instanzen pro Host. Die Snapshot-Geschwindigkeit bestimmt direkt das Nutzererlebnis: Ob man nach einer Codeausführungsanforderung des Agenten 100 ms oder 5 Sekunden wartet, ist der Unterschied zwischen dauerhafter Nutzung und Abbruch.
Credential-Abschirmung auf Netzwerkebene. Dies ist für Agent-Szenarien besonders kritisch. Der Agent muss auf das Internet zugreifen (Abhängigkeiten ziehen, APIs aufrufen), aber man möchte nicht, dass er die Secrets aus den Umgebungsvariablen liest. Lambda MicroVMs lösen das mit Short-Lived-Auth-Token + Proxy-Header; Matchlock setzt auf Deny-All + Domain-Whitelist. Der Unterschied liegt nicht im Ob, sondern in den unterschiedlichen Sicherheitsmodell-Verständnissen der Anbieter.
SSH/VPN-Zugang. Interaktive Entwicklungsszenarien erfordern, dass Entwickler direkt in die Sandbox einsteigen und debuggen können. Fly.io Sprites und E2B unterstützen SSH; Lambda MicroVMs arbeiten derzeit im HTTP-Endpunkt-Modus, der besser zur Codeausführung als zur interaktiven Entwicklung passt.
Orchestrierung und K8s-Integration. Kata Containers ist in dieser Dimension nahezu konkurrenzlos – es wurde für Kubernetes entwickelt. Nacktes Firecracker erfordert umfangreiche Eigenentwicklung von Infrastruktur; Lambda MicroVMs delegieren diese Verantwortung an den Managed Service von AWS. libkrun fehlt derzeit eine clusterweite Orchestrierungslösung.
Agent-Freundlichkeit. Dies betrifft Produktdesign-Philosophie, nicht rein technische Spezifikationen. Bietet die Sandbox eine REST-API? Unterstützt sie SDKs? Passt die Semantik von Snapshot/Resume zum »Ausführen-Warten-auf-Ergebnis-Weiterausführen«-Zyklus des Agenten? Lambda MicroVMs’ Suspend/Resume-Mechanismus und das 8-Stunden-Limit sind offensichtlich für Agent-Sessions konzipiert; Docker Sandboxes’ »ein Docker-Daemon pro Agent«-Modell ist stärker auf lokale Entwicklungsszenarien ausgerichtet.
Die Karten sind noch nicht gemischt
Im langen Zeitstrahl betrachtet: Als Firecracker 2018 entstand, war die MicroVM ein Optimierungsmittel auf Infrastrukturebene – Lambda schneller, sparsamer, sicherer zu machen. 2026 ist dieselbe Technologie zum Bürger erster Klasse auf Produktebene geworden, weil sich die Anforderungen der oberen Schicht fundamental verändert haben: Agenten müssen Code ausführen, Codeausführung braucht Sandboxen, und Sandboxen können nicht aus zusammengeflickten Namespaces bestehen.
Aber die Frage »Welches ist die beste Sandbox?« hat keine einheitliche Antwort. Wenn dein Agent nur JavaScript ausführt, sind Cloudflare Workers’ V8 Isolates möglicherweise stärker als eine MicroVM mit Millisekunden-Start. Wenn du auf Kubernetes läufst und langlebige isolierte Pods brauchst, ist Kata Containers pragmatischer als nacktes Firecracker. Wenn du eine lokale, selbstgehostete, leichtgewichtige Lösung benötigst, sind libkrun + Microsandbox flexibler als ein AWS Managed Service. Lambda MicroVMs’ Stärken liegen in Zero-Ops und Snapshot-Wiederherstellung – aber sie binden an das AWS-Ökosystem, ARM64-Architektur und regionale Beschränkungen.
Ich habe keine der genannten Sandbox-Lösungen in großem Maßstab in Produktion betrieben. Die Beurteilungen in diesem Text beruhen auf der Kreuzvalidierung öffentlicher Dokumentation, technischer Whitepapers und Community-Diskussionen. Wer derzeit eine Sandbox-Infrastruktur für KI-Agenten evaluiert, dem sei empfohlen, die eigene Arbeitslast mit Benchmarks zu prüfen – 100 ms Snapshot-Wiederherstellung unter realen Netzwerklatenzbedingungen können sich völlig anders anfühlen als die Zahlen in einer Benchmark-Tabelle.
Architekturentscheidungen fallen selten auf der Architekturebene. In einer Welt, in der ein Agent dutzende Male pro Sekunde Codeausführungsanfragen stellt, könnten Snapshot-Geschwindigkeit, Netzwerklatenz, Schlüsselverwaltung und Abrechnungsmodell – diese »nicht-essenziellen« Faktoren – am Ende wichtiger sein als die Frage, ob der VMM in Rust oder Go geschrieben ist.
Offenlegung: Dieser Text ist eine reine Technologiebeobachtung. Der Autor hat keine finanziellen Interessen an den genannten Unternehmen oder Projekten.