AWS-Emulator: Amazons Cloud läuft jetzt auf dem Laptop – kein Mensch hat den Code geschrieben

Worum es geht

Amazon Web Services (AWS), der größte Cloud-Anbieter der Welt, hat am 11. November 2026 den AWS Emulator veröffentlicht. Das ist ein kostenloses Programm, das die Cloud-Dienste von AWS auf dem eigenen Rechner nachahmt. Entwickler – und zunehmend KI-Programmierassistenten – können damit ihren Code gegen eine Art lokale Kopie von AWS testen, statt dafür echte, kostenpflichtige Ressourcen in der Cloud anzulegen. Laut AWS News Blog ist das Werkzeug ab sofort allgemein verfügbar, es fällt keine zusätzliche Gebühr an. Bezahlen muss man erst, wenn man wirklich in die Cloud ausrollt.

Für Schlagzeilen sorgt aber vor allem, wer den Emulator gebaut hat. Matthew Goldberg, Senior Principal Engineer bei AWS, schreibt in einem Beitrag auf About Amazon:

„Der Emulator wurde vollständig von autonomen Agenten geschrieben. Unser Team hat keine einzige Zeile des Codes geschrieben oder geprüft.“

Der Quellcode liegt öffentlich auf GitHub, und zwar unter CC0. Das ist eine Erklärung, mit der der Code gemeinfrei wird; jeder darf ihn ohne Bedingungen nutzen. Ausgenommen ist laut Unite.AI eingebundener Fremdcode, der unter Apache 2.0 steht. Die komplette Commit-Historie ist ebenfalls einsehbar.

Wie der Emulator funktioniert

Der Emulator ist in Rust geschrieben, damit er wenig Rechenleistung und Arbeitsspeicher braucht. Er läuft als lokaler Webserver und nimmt HTTPS-Anfragen unter der Adresse 127.0.0.1:9297 an. Standardmäßig kommt also nur der eigene Rechner an ihn heran. Auf Linux installiert man ihn aus RPM- oder Debian-Paketen. Auf macOS und Windows muss man aus einem kurzen Dockerfile in der Dokumentation selbst ein Docker-Image bauen, also einen abgeschotteten Software-Container, denn ein fertiges Image stellt AWS nicht bereit. Alternativ lässt sich das Programm aus dem Quellcode kompilieren. Simon Willison hofft, dass AWS hier nachbessert: Am schönsten wäre aus seiner Sicht eine einzelne Programmdatei, die man in Testumgebungen beliebiger Sprachen und Plattformen einfach mitlaufen lassen kann.

Die AWS-Kommandozeile (CLI), die Programmierbibliotheken (SDKs) und Coding-Agenten wie Amazons Kiro oder Anthropics Claude Code leitet man über Umgebungsvariablen wie AWS_ENDPOINT_URL auf den Emulator um. Der eigentliche Anwendungscode muss sich dafür nicht ändern. Ein Test, der eine DynamoDB-Tabelle anlegt, einen Eintrag schreibt und wieder ausliest, läuft dann komplett auf dem Laptop, ganz ohne Internetverbindung. Für Rust-Projekte gibt es zusätzlich einen eingebetteten Modus (das Paket aws-emulator-embedded), der den Emulator direkt im Testprozess startet. Jede Instanz hat dabei ihren eigenen Zustand, Tests können also parallel laufen. Ressourcen werden im Arbeitsspeicher gehalten und beim Beenden gelöscht.

Eine Sicherheitsvorkehrung gibt es auch: Der Emulator akzeptiert nur Zugangsschlüssel, die mit „EMULATOR“ beginnen.

Wie nah ist der Emulator an der echten Cloud?

Grundlage sind die öffentlichen API-Modelle von AWS (im Smithy-Format). Das sind maschinenlesbare Beschreibungen, wie sich jeder Dienst verhalten soll, und dieselben Modelle nutzen auch die offiziellen SDKs. Anfragen und Fehlermeldungen sehen deshalb so aus wie bei AWS. Laut Goldberg begann das Projekt als leerer Webserver, der Anfragen für 438 API-Modelle annahm. GeekWire spricht von mehr als 400 API-Modellen für über 200 Dienste. InfoWorld schreibt dagegen, der Emulator unterstütze „alle 426 AWS-Dienste“. Die Angaben gehen also auseinander, und „unterstützt“ heißt ohnehin nicht „vollständig nachgebaut“.

Wie gut ein Dienst nachgebildet ist, misst AWS mit sogenannten Fidelity-Tests, also Übereinstimmungstests. Das sind kurze, geskriptete Abläufe wie „Warteschlange anlegen, Nachricht senden, Warteschlange löschen“, die vorher gegen die echte AWS-Cloud geprüft wurden. Bestanden hat der Emulator einen solchen Test nur, wenn er bei jedem Aufruf genau dieselbe Antwort liefert, inklusive Statuscode, Inhalt und exaktem Fehlertext. Jeder Test wurde laut Unite.AI gegen mindestens zwei getrennte AWS-Testkonten verifiziert. Mit jedem Release veröffentlicht AWS pro Dienst einen Wert nach dem Muster „k von n“ bestandenen Tests. AWS weist selbst darauf hin, dass der Wert sinken kann, wenn neue Tests dazukommen, obwohl der Emulator besser geworden ist. Verhalten ohne passenden Test gilt ausdrücklich als nicht verifiziert.

Funktionen, die noch fehlen, liefern einen Fehler zurück, statt stillschweigend Erfolg zu melden. Laut shiftdelete.net und Unite.AI ist das HTTP 501 („Not Implemented“), InfoWorld nennt HTTP 503. Die Liste bekannter Lücken führen die Agenten öffentlich in einem GitHub-Ordner mit dem Namen „things-that-do-not-work“.

Gebaut von drei Agenten-Teams

Angefangen hat alles als Wochenendexperiment. Inspiriert war es von Anthropics Demonstration Anfang des Jahres, bei der ein Team aus Claude-Agenten einen C-Compiler gebaut hatte. Goldberg gab dem Coding-Agenten Kiro eine dreiteilige Anweisung: Tests schreiben, sie gegen das echte AWS prüfen und eine Implementierung im Arbeitsspeicher bauen, die diese Tests besteht. Nach rund 15 Minuten stand ein brauchbarer Nachbau von Amazon SQS, dem Warteschlangen-Dienst. Bis Sonntagabend hatte Kiro laut GeekWire eine grobe Version des restlichen AWS gebaut, mit offensichtlichen Lücken. Schon am Montag nutzte Goldbergs Team sie für eigene Tests.

Die Produktversion betreiben heute drei Agenten-Teams auf Amazon Bedrock AgentCore, AWS' Plattform zum Ausführen von KI-Agenten:

Jede Änderung muss durch ein sogenanntes Merge-Gate, eine automatische Schranke vor der Übernahme in den Code. Dort wird geprüft, ob alles kompiliert, ob die Codier-Standards eingehalten sind und ob die Übereinstimmung mit AWS erhalten bleibt. Außerdem sucht ein eigener Sicherheitsagent gezielt nach Schwachstellen, einmal während der Entwicklung und noch einmal in der Release-Pipeline. „Ohne diese Freigabeschranke würden wir dem, was unsere Agenten bauen, nicht vertrauen“, schreibt Goldberg. Hunderte Agenten arbeiten parallel und beheben nach seinen Angaben täglich Tausende Probleme. Simon Willison zählt 29.684 Commits in den ersten drei Wochen. Pull Requests von außen nimmt das Repository nicht an, Fehler kann man aber über GitHub Issues melden.

Menschen haben das Gerüst gebaut: Spezifikationen, Testinfrastruktur, Merge-Gates und Release-Pipeline. Swami Sivasubramanian, AWS-Vizepräsident für agentische KI, erzählt dazu in einem Gastbeitrag im Blog von CTO Werner Vogels ein Beispiel. Er ließ Kiro eine Replikations-Engine des frühen Amazon-Sperrdienstes „Alf“ neu bauen. Von Hand hatte die Entwicklung damals rund vier Monate gedauert. Mit Kiro brauchte es zunächst vier Nächte unter Aufsicht, weil der Agent seine Ergebnisse nicht überprüfen konnte. Mit Spezifikation und Testumgebung war es in etwa zwei Stunden erledigt. Seine Folgerung: Ingenieure werden zu „Systemorchestratoren“, die festlegen, was korrekt ist, während Agenten den Code schreiben.

Grenzen zum Start

• Keine echte Rechteprüfung: Der Emulator wertet IAM, das Rechte- und Zugriffssystem von AWS, sowie ressourcenbasierte Richtlinien nicht so aus wie AWS. Eine Anfrage, die AWS ablehnen würde, kann lokal also durchgehen. AWS sagt ausdrücklich, man solle damit nicht testen, ob eine App sicher ist.
• Ein Konto, keine Regionen: Jede Instanz verhält sich wie ein einzelnes Konto (000000000000). Konto- oder regionsübergreifendes Verhalten gibt es nicht.
• Keine Fehlersimulation: Laut IDC-Analyst Devin Pratt (gegenüber InfoWorld) simuliert der Emulator weder Drosselung (Throttling) noch Ausfälle, Snapshots oder regionale Unterschiede. Advait Patel, SRE bei Broadcom, warnt: Genau das lege Systeme in der Produktion lahm. Wer nie einen Fehler 429 oder ein Timeout sieht, testet auch seine Wiederholungslogik nie. Es drohe falsche Sicherheit, wenn „lokal bestanden“ als „fertig zum Ausliefern“ gilt.
• Keine Sandbox: Der ausgeführte Code wird nicht abgeschottet. Stecken echte Produktionszugangsdaten in einer lokal getesteten Funktion, kann sie laut Pratt trotzdem auf reale AWS-Ressourcen zugreifen.
• Telemetrie ist eingeschaltet: Standardmäßig sendet der Emulator anonyme Nutzungs- und Fehlerdaten, bis man das abschaltet.

Reaktionen

Ashish Chaturvedi von HFS Research sieht den Nutzen vor allem bei Abläufen über mehrere Dienste hinweg, etwa S3, Lambda, DynamoDB und API Gateway. Dazu kommt weniger Ballast in gemeinsam genutzten Konten. Viele Kunden hätten schon Monate später einen vergessenen Test-Bucket auf der Rechnung gefunden. Patel sieht den größten Vorteil bei Coding-Agenten: Ihr Kreislauf aus Schreiben, Ausführen, Fehler lesen und Korrigieren schrumpfe pro Durchgang „von Minuten auf Sekunden“, und Agenten könnten frei experimentieren, ohne in einem echten Konto etwas Teures anzulegen. Chaturvedi nennt das für IT-Chefs einen Weg zu einer „sichereren Einführung von Agenten“. Mehr Details will AWS auf der Konferenz re:Invent zeigen.

Einordnung

Der Zeitpunkt ist kein Zufall. LocalStack, der bekannteste AWS-Emulator eines Drittanbieters, hat seine Gratisversion in diesem Jahr laut GeekWire an ein Benutzerkonto gekoppelt und auf nichtkommerzielle Nutzung beschränkt. Ein kostenloser, gemeinfreier Emulator direkt von AWS mit öffentlich einsehbaren Übereinstimmungswerten ist eine direkte Antwort darauf. Er passt auch zu einer Zeit, in der KI-Agenten Hunderte Testläufe pro Stunde fahren.

Trotzdem gilt: Der Emulator gibt schnelle Rückmeldung, ersetzt aber nicht die Abschlussprüfung. Sicherheit, Rechte und Verhalten bei Ausfällen muss man weiter gegen das echte AWS testen. Wer ihn einsetzen will, sollte die Übereinstimmungswerte für jeden genutzten Dienst prüfen, echte Zugangsdaten aus den Testjobs entfernen und bei Bedarf die Telemetrie abschalten.

Und das Versprechen „kein Mensch hat den Code geprüft“ ist nur so belastbar wie die Tests und Schranken drumherum. Spannend ist daher weniger die Schlagzeile als die öffentliche Testsuite: Sie macht nachprüfbar, was der Emulator kann und was nicht. Das Projekt ist ein großer Praxistest dafür, ob agentisch erzeugte Software in dieser Größenordnung verlässlich genug für den Alltag von Entwicklern ist.