--- title: "microVMs erklärt: Firecracker vs. gVisor für sichere Workloads 2026" description: "Ein praxisnaher Vergleich 2026 von Firecracker-microVMs und gVisor für sichere Workload-Isolation: wie beide Sandboxes funktionieren, die Sicherheits- und Performance-Kompromisse und wann KVM-basierte VMs die bessere Wahl sind." author: Aleksei Aleinikov date: 2026-06-18 updated: 2026-06-27 lang: de tags: [microvms, firecracker, gvisor, sandboxing, kubernetes, security, devops] canonical: https://www.alekseialeinikov.com/de/blog/topics/devops/microvms-firecracker-vs-gvisor-sichere-workloads-2026 source: alekseialeinikov.com --- # microVMs erklärt: Firecracker vs. gVisor für sichere Workloads 2026 Ein Linux-Container teilt sich einen Kernel mit allem anderen auf dem Host. Genau dieser eine geteilte Kernel ist auch der größte Teil der Angriffsfläche. In dem Moment, in dem eine Multi-Tenant-Plattform Code ausführt, dem sie nicht vollständig vertraut — Kundenfunktionen, CI-Jobs, KI-Agenten, die Tools ausführen — ist dieser geteilte Kernel kein Implementierungsdetail mehr, sondern eine Sicherheitsentscheidung. **Firecracker** und **gVisor** sind die beiden am häufigsten eingesetzten Antworten auf diese Entscheidung. Beide schieben eine Isolationsschicht zwischen einen nicht vertrauenswürdigen Workload und den Host-Kernel, tun das aber auf grundlegend verschiedene Weise. Dieser Artikel erklärt, wie beide funktionieren, wo ihre Stärken liegen, wo nicht, und wie man in der Produktion zwischen ihnen wählt. ![microVMs: Firecracker vs. gVisor — sichere Workload-Isolation 2026](https://www.alekseialeinikov.com/blog/microvms-firecracker-vs-gvisor-2026.webp) ## Das Problem: ein geteilter Kernel Standard-Container-Runtimes — Docker, containerd, CRI-O — isolieren Prozesse mit Linux-**Namespaces** und **cgroups** und schränken Syscalls über **seccomp** und Capabilities ein. Für vertrauenswürdigen Code ist das eine gute Isolation. Es ist aber keine Sicherheitsgrenze, auf die man eine Multi-Tenant-Plattform setzen möchte. Der Grund ist einfach: Jeder Container ruft direkt in **denselben Host-Kernel**. Der Linux-Kernel stellt rund 350 Systemaufrufe bereit, und ein einziger ausnutzbarer Fehler in einem davon kann zu einem Container-Ausbruch werden. Namespaces verringern, was ein Prozess sehen kann; sie ändern nicht, welcher Kernel seine Syscalls bearbeitet. Die Frage für nicht vertrauenswürdige Workloads lautet also: **Wie verhindern wir, dass ein kompromittierter Workload direkt den Host-Kernel erreicht?** Firecracker und gVisor geben zwei verschiedene Antworten. ## Wie Firecracker funktioniert **Firecracker ist ein Virtual Machine Monitor (VMM).** Von AWS in Rust entwickelt, betreibt es AWS Lambda und AWS Fargate. Statt den Host-Kernel zu teilen, bootet jede Firecracker-microVM ihren **eigenen Gast-Kernel** auf Basis von Hardware-Virtualisierung (KVM). Die Isolationsgrenze ist die Hardware-Virtualisierungsschicht. Ein nicht vertrauenswürdiger Workload spricht mit seinem eigenen Gast-Kernel; dieser ist durch die Virtualisierungsfunktionen der CPU vom Host getrennt. Um den Host zu erreichen, müsste ein Angreifer aus dem Gast-Kernel **und** aus der VM ausbrechen — eine deutlich höhere Hürde als das Ausnutzen eines einzelnen Host-Syscalls. Firecracker bleibt schnell, weil es bewusst minimal ist: - Ein reduziertes Gerätemodell — nur `virtio-net`, `virtio-block`, eine serielle Konsole und ein einfacher Tastatur-Controller. Kein BIOS, kein PCI, kein USB. - Eine Bootzeit von rund **125 ms** bis zum Anwendungscode. - Ein Speicher-Overhead von etwa **5 MB** pro microVM. - Ein Firecracker-Prozess pro VM, zusätzlich abgesichert mit seccomp, Namespaces und cgroups. Diese Kombination — eine echte VM-Grenze bei nahezu Container-Startzeit — ist der Grund, warum Firecracker zum Standard für Serverless-Plattformen wurde, die Millionen kurzlebiger, nicht vertrauenswürdiger Aufrufe ausführen. ## Wie gVisor funktioniert **gVisor verfolgt den umgekehrten Ansatz: Es nutzt überhaupt keine Hardware-Virtualisierung.** Von Google entwickelt und in Google Cloud Run sowie GKE Sandbox eingesetzt, schiebt gVisor einen **Userspace-Kernel** — eine Komponente namens `runsc` — zwischen Workload und Host. Wenn ein Sandbox-Prozess einen Systemaufruf macht, erreicht dieser nie direkt den Host-Kernel. Der Aufruf wird abgefangen und vom eigenen, in Go geschriebenen Kernel von gVisor bedient, der einen großen Teil der Linux-Syscall-Oberfläche im Userspace nachbildet. Nur ein kleiner, streng kontrollierter Satz an Operationen wird an den Host weitergereicht. Das Ergebnis ist eine drastisch **kleinere Host-Angriffsfläche**. Der Workload darf jeden beliebigen Syscall absetzen, spricht dabei aber mit `runsc`, nicht mit dem Host. Ein Fehler im emulierten Syscall betrifft die Sandbox, nicht den Host-Kernel. Die Kompromisse unterscheiden sich von Firecracker: - **Kein KVM erforderlich**, was in Umgebungen mit verschachtelter Virtualisierung zählt, in denen keine Hardware-Virtualisierung verfügbar ist (manche Cloud-VMs, manche CI-Runner). - **Syscall-Overhead**: Jeder abgefangene Aufruf zahlt einen Userspace-Umweg. Syscall- und I/O-lastige Workloads spüren das am stärksten. - **Kompatibilitätslücken**: Da gVisor den Kernel nachbildet, werden einige seltenere Syscalls oder `/proc`-Funktionen nicht unterstützt oder verhalten sich anders. ## Firecracker vs. gVisor im direkten Vergleich | Dimension | Firecracker (microVM) | gVisor (Userspace-Kernel) | |---|---|---| | Isolationsmechanismus | Hardware-Virtualisierung (KVM) | Abgefangene Syscalls im Userspace (`runsc`) | | Gast-Kernel | Eigener echter Linux-Kernel | Nachgebildeter Kernel in Go | | Benötigt KVM / Bare Metal | Ja | Nein | | Boot / Start | ~125 ms | Schneller Prozessstart, kein VM-Boot | | Host-Angriffsfläche | Sehr klein (VM-Grenze) | Klein (begrenzte Host-Syscalls) | | Kompatibilität | Hoch (echter Kernel) | Gut, mit Lücken bei seltenen Syscalls | | Ideal für | Starke Isolation, Serverless, Multi-Tenant-Codeausführung | Container-natives Sandboxing ohne KVM | | Bekannte Nutzer | AWS Lambda, AWS Fargate | Google Cloud Run, GKE Sandbox | ## Performance: Was dich wirklich kostet Die ehrliche Zusammenfassung lautet: **Keine der beiden Optionen ist kostenlos**, und die Kosten zeigen sich an unterschiedlichen Stellen. Firecracker zahlt seinen Preis bei **Boot und Speicher**: Man startet eine echte (wenn auch winzige) VM, also gibt es eine Kernel- und Speicheruntergrenze pro VM. Für langlaufende Dienste ist dieser Overhead vernachlässigbar; für sehr kurzlebige Sub-Sekunden-Workloads ist es die Stellschraube, die man optimiert. gVisor zahlt seinen Preis **pro Syscall**. CPU-lastige Arbeit, die den Kernel selten anfasst, läuft nahezu nativ. Workloads, die den Kernel jedoch beanspruchen — viele kleine Netzwerkaufrufe, intensive Datei-I/O, häufiges `fork`/`exec` — zahlen eine messbare Abgabe, weil jeder dieser Aufrufe abgefangen wird. Eine nützliche Faustregel: - **Rechenintensiv, syscall-arm** → der Overhead von gVisor ist gering. - **I/O- oder syscall-lastig** → das Modell von Firecracker gewinnt oft. - **Stärkste Isolation pro Risiko-Euro** → die VM-Grenze von Firecracker ist für Compliance leichter zu begründen. ## Wie man wählt Die Entscheidung dreht sich selten darum, welche Technologie „besser“ ist. Es geht um deine Rahmenbedingungen. Hier ist das Framework, das ich verwende. **Wähle Firecracker, wenn:** - Du wirklich nicht vertrauenswürdigen, Multi-Tenant-Code ausführst (Functions-as-a-Service, von Kunden eingereichte Jobs, sandboxed KI-Tool-Ausführung). - Du KVM bekommst (Bare Metal oder verschachtelte Virtualisierung ist verfügbar). - Du die sauberste mögliche Isolationsgeschichte für Auditoren willst: Eine VM-Grenze ist gut verstanden. **Wähle gVisor, wenn:** - Du keine Hardware-Virtualisierung bekommst (manche Managed-Umgebungen, verschachteltes CI). - Du container-native Ergonomie und eine OCI-Runtime (`runsc`) als Drop-in unter Kubernetes willst. - Deine Workloads rechengebunden und tolerant gegenüber kleineren Syscall-Kompatibilitätslücken sind. **Bleib bei Standard-Containern + seccomp, wenn:** - Der Code vertrauenswürdig ist (deine eigenen Dienste) und Namespaces, cgroups, seccomp und ein gehärtetes Profil eine angemessene Grenze sind. Zahle keinen Isolations-Overhead, den du nicht brauchst. ## Wo das in einer Sicherheitsarchitektur einzuordnen ist microVMs und Userspace-Kernel sind eine Schicht, keine vollständige Strategie. In einem Defense-in-Depth-Design stehen sie neben, nicht anstelle von: - Least-Privilege-IAM und kurzlebigen Credentials, - Network Policy und Egress-Kontrolle um die Sandbox, - seccomp und Capability-Dropping auch innerhalb der Sandbox, - Image-Provenance und Supply-Chain-Verifizierung dessen, was überhaupt läuft. Die Sandbox begrenzt den **Schadensradius**, wenn etwas in ihr kompromittiert wird. Sie macht die übrigen Kontrollen nicht überflüssig. ## Fazit für 2026 Der geteilte Host-Kernel ist die stille Annahme hinter den meisten Container-Deployments — und das ist in Ordnung, bis du Code ausführst, dem du nicht vertraust. Ab diesem Punkt brauchst du eine echte Grenze. **Firecracker** liefert diese Grenze über Hardware-Virtualisierung bei nahezu Container-Startzeit, weshalb es Serverless im großen Maßstab trägt. **gVisor** liefert eine kleinere Host-Angriffsfläche ohne KVM, weshalb es zu container-nativen Plattformen passt, die kein Bare Metal voraussetzen können. Entscheide anhand von drei Dingen: ob du KVM bekommst, wie syscall-lastig deine Workloads sind und wie stark die Isolationsgeschichte sein muss, die deine Auditoren erwarten. Passe die Grenze an die Bedrohung an — und zahle nicht für Isolation, die deine Workloads nicht brauchen.