AWS verpasst der eigenen Serverless-Plattform ein neues Fundament für eine Aufgabe, die bisher jedes Team selbst lösen musste: fremden Code sicher laufen lassen. Mit Lambda MicroVMs stellt der Cloud-Anbieter isolierte Sandboxen bereit, die sich vollständig steuern lassen. Für alle, die KI-Agenten bauen, verschiebt sich damit eine zentrale Sicherheitsfrage zum Plattformbetreiber.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Lambda MicroVMs bringen serverlose Sandboxen mit echter Virtual-Machine-Isolation, die sich starten, anhalten und fortsetzen lassen. AWS richtet das Angebot ausdrücklich an Anwendungen, die von Menschen oder von KI erzeugten Code ausführen. Kennen Sie das Risiko, fremden Code auf eigener Infrastruktur laufen zu lassen? Genau hier setzt eine harte Grenze zwischen den Sitzungen an.

Das Wichtigste in Kürze

  • AWS Lambda MicroVMs liefern pro Sitzung eine eigene, per Firecracker isolierte virtuelle Maschine ohne geteilten Kernel.
  • Jede MicroVM erlaubt bis zu 16 vCPUs, 32 GB Arbeitsspeicher und acht Stunden Laufzeit, mit Pause und Fortsetzung aus einem Snapshot.
  • Das Angebot zielt auf KI-Agenten, Coding-Assistenten und andere Workloads mit untrusted Code.
  • Für DACH-Unternehmen entscheidet der Datenstandort: verfügbar unter anderem in Irland, ein deutscher Standort fehlt noch.

Wie unterscheiden sich MicroVMs von Containern?

Ein geöffneter Safe zeigt eine rauchende Miniaturdampfmaschine und ein Schild „MicroVM“
Firecracker-Virtualisierungstechnik für AWS Lambda: Jede Sitzung erhält eine isolierte MicroVM mit eigenem Kernel und Dateisystem für erhöhte Sicherheit

Der Kern liegt in Firecracker, der Virtualisierungstechnik, auf der laut AWS über 15 Billionen Lambda-Aufrufe pro Monat laufen. Jede Sitzung bekommt eine eigene MicroVM mit eigenem Kernel, eigenem Dateisystem und getrenntem Netzwerk-Namespace. Anders als ein Container teilt eine MicroVM keinen Kernel mit dem Host, weshalb ein Ausbruch über eine Kernel-Lücke deutlich schwerer fällt.

Die zweite Neuerung betrifft den Lebenszyklus. Aus einem Dockerfile baut Lambda ein Image und friert den initialisierten Zustand als Snapshot ein. Aus diesem Snapshot startet die MicroVM nahezu sofort, läuft bis zu acht Stunden, hält bei Leerlauf automatisch an und nimmt die Arbeit mit vollem Speicher- und Datenstand wieder auf. So bleibt der Zustand eines Agenten über Pausen hinweg erhalten, ohne durchgehend zu kosten.

Warum braucht jeder KI-Agent eine eigene Sandbox?

Zwei Gartenzwerge vor einem Regal mit drei beschrifteten Safes
Jeder KI-Agent bekommt eine eigene abgeschottete Box, in der fremder Code keinen Zugriff auf andere Sitzungen hat.

Der Schritt steht für ein Muster, das den Cloud-Markt seit Monaten prägt: eine eigene Ausführungsgrenze pro Aufgabe. Spezialisten wie E2B setzen wie AWS auf Firecracker mit Boot-Zeiten um 200 Millisekunden, Modal nutzt Googles gVisor für viele kurze Aufgaben, Cloudflare wirbt mit Kaltstarts unter 50 Millisekunden. AWS rückt diese Schutzschicht aus dem Spezialmarkt in die größte Cloud-Plattform.

Der Grund ist handfest. Ein KI-Agent generiert Code, der zur Laufzeit entsteht und vorher niemand geprüft hat. Ohne harte Trennung kann ein manipulierter Auftrag den Zustand eines anderen Nutzers lesen oder die darunterliegende Infrastruktur angreifen. Eine MicroVM gibt jeder Aufgabe einen abgeschotteten Raum, in dem fremder Code keinen Zugriff auf andere Sitzungen erhält. Wie AWS seine Cloud insgesamt auf solche Agent-Workloads umbaut, zeigt der Umbau hinter den Kulissen.

MicroVMs verschieben die Sicherheitslast vom Entwickler zur Plattform. Für den deutschen Mittelstand zählt aber nicht nur die Isolation, sondern die Frage, in welchem Rechenzentrum der Agent tatsächlich rechnet.

— Michael Dobler, Herausgeber Dr. Web

Was bedeutet das für Unternehmen im DACH-Raum?

EU-Flagge neben einem Koffer mit dem Schriftzug Standort: Irland und durchgestrichenem Frankfurt
Der Datenstandort entscheidet: Die Sandboxen laufen unter anderem in Irland, ein deutsches Rechenzentrum fehlt vorerst.

Beim Datenstandort wird der Komfort zur Stolperfalle. AWS bietet die MicroVMs zunächst in den USA, in Irland und in Tokio an, ein deutscher Standort fehlt. Unter DSGVO und mit Blick auf den US-Behördenzugriff über den CLOUD Act bleibt die Region für personenbezogene Daten entscheidend. Wer einen souveränen Pfad sucht, findet im Markt Alternativen, etwa SAPs europäische KI-Cloud oder den 250-Millionen-Auftrag für eine staatliche KI-Cloud.

Konkret empfehlen sich drei Schritte. Prüfen Sie vor dem Einsatz, ob die verarbeiteten Daten personenbezogen sind und ob ein Standort innerhalb der EU genügt. Vergleichen Sie die Kosten einer dauerhaft laufenden VM bei einem deutschen Hoster mit dem nutzungsbasierten Modell von AWS, gerade bei vielen kurzen Agent-Aufgaben. Für planbare Dauerlast lohnt oft ein eigener Server, wie ihn unser Hosting-Vergleich zeigt. Eine Einordnung der Werkzeuge dahinter liefert der Überblick zu KI-Tools.

Mehr Newshunger?

Ein grüner Gummibär in einem verschlossenen Glaskasten mit Vorhängeschloss
AWS modernisiert seine Cloud-Infrastruktur für KI-Agenten. SAP bietet EU-konforme KI-Cloud-Lösungen an. T-Systems und SAP erhalten Auftrag für Bundes-KI-Cloud
4,4 150 Bewertungen

Wie hat Ihnen dieser Artikel gefallen?