AWS stellt AWS Emulator für lokale Tests von AWS-Anwendungen vor

AWS Emulator bringt die AWS-API auf den eigenen Rechner

AWS hat den AWS Emulator im AWS News Blog vorgestellt, in einem Beitrag von Daniel Abib vom 11. November 2026. Es handelt sich um einen lokalen Emulator für Amazon Web Services, der auf dem Rechner des Entwicklers läuft. Die AWS CLI, die AWS-SDKs und Coding-Agenten sprechen ihn über einen lokalen HTTPS-Endpunkt an, mit denselben AWS-APIs, die sie auch in der Cloud verwenden. Laut AWS fällt keine zusätzliche Servicegebühr an. Bezahlt werden nur AWS-Ressourcen, die man tatsächlich auf AWS bereitstellt. Der Quellcode ist auf GitHub veröffentlicht. Unter Linux installiert man ihn aus einem RPM- oder Debian-Paket. Unter macOS und Windows läuft er in Docker. Ein fertiges Image bietet AWS nicht an, man baut es selbst aus einem kurzen Dockerfile der Dokumentation.

So läuft ein lokaler Start ab

Der Ablauf ist einfach. Man installiert das Paket, startet den Befehl aws-emulator und richtet die Werkzeuge auf den lokalen Endpunkt aus. Beim Start erzeugt der Emulator eigene Zugangsdaten, eine Konfigurationsdatei und ein Zertifikat und legt sie unter ~/.aws/emulator/9297/ ab. Er bedient HTTPS auf 127.0.0.1:9297, sodass nur der eigene Rechner ihn erreicht. Danach setzt man einige Umgebungsvariablen, etwa AWS_ENDPOINT_URL, und entfernt alle Variablen, die echte AWS-Zugangsdaten liefern könnten. Der Anwendungscode bleibt unverändert.

Bei jedem Start entstehen neue Schlüssel. Die Zugriffsschlüssel-IDs beginnen mit EMULATOR, damit man sie nicht mit echten Schlüsseln verwechselt, und Anfragen mit anderen Schlüsseln lehnt der Emulator ab. Er nutzt genau ein Konto mit der Nummer 000000000000. In der Vorführung legt der Autor einen S3-Bucket an und kopiert ein Objekt hinein. Danach bittet er den Coding-Agenten Kiro, eine Amazon-DynamoDB-Tabelle zu erstellen, einen Eintrag zu schreiben und wieder zu lesen, alles gegen den lokalen Endpunkt und nicht gegen ein echtes Konto. Eine vorhandene Testsuite lässt sich genauso nutzen: Emulator starten, dieselben Variablen im Testskript setzen und die Tests wie gewohnt ausführen.

Der eingebettete Modus für schnelle, getrennte Tests

Für Tests gibt es eine zweite Möglichkeit. Der eingebettete Modus erzeugt den Emulator direkt im Testprozess und bindet ihn über den HTTP-Client in das SDK ein. Jede eingebettete Instanz hat ihren eigenen Zustand. Tests teilen sich also keine Buckets, Tabellen oder Warteschlangen und können in großer Zahl parallel laufen. Zum Start gibt es diesen Modus nur für das AWS SDK for Rust, über die Bibliothek aws-emulator-embedded. Läuft der Emulator als eigener Prozess, brauchen manche SDKs eine zusätzliche Einstellung, um seinem Zertifikat zu vertrauen. Der Beitrag nennt als Beispiel den Truststore des AWS SDK for Java. Als Prozess verlangt er für jede Anfrage eine SigV4-Signatur und bietet den Endpunkt /__admin/health, damit ein Skript oder ein Container wartet, bis er bereit ist.

Wie AWS die Genauigkeit misst

Ein Emulator hilft nur, wenn ein lokal bestandener Test auch auf AWS bestehen würde. Deshalb setzt AWS Fidelity-Tests ein. Jeder ist ein kurzes Programm, das mit einem AWS-SDK einen Ablauf ausführt und das Verhalten von AWS prüft. Jeden Test hat AWS zuvor gegen das echte AWS verifiziert. Er gilt nur als bestanden, wenn der Emulator bei jeder Antwort mit AWS übereinstimmt, also bei Statuscode, Inhalt, genauem Fehlercode samt Meldung und den Ressourcen, die der Ablauf erzeugt. Mit jeder Version veröffentlicht AWS pro Dienst eine Bewertung in der Form k von n. Die Testmenge ist im Repository aws-emulator-evaluation-suite öffentlich, auch mit Tests, die noch scheitern. AWS warnt außerdem, dass eine Bewertung sinken kann, wenn neue Tests hinzukommen, selbst wenn der Emulator besser wird. Ist eine Operation noch nicht umgesetzt, antwortet der Emulator mit HTTP 501, und der Test schlägt sofort fehl, statt zufällig zu bestehen.

Gebaut und geprüft von Agenten

Nach Angaben von AWS bauen und pflegen Agenten den Emulator aus den AWS-API-Modellen, mit Amazon Bedrock AgentCore Runtime Instances, AWS CodePipeline und AWS CodeCommit. Eine Gruppe von Agenten sucht nach Lücken und legt für jede ein Ticket an. Eine zweite Gruppe schreibt Tests, setzt das Verhalten um und prüft die Änderung. Ein Push löst dann die Pipeline aus, die die Fidelity-Tests ausführt, bevor etwas im öffentlichen Repository erscheint. Ein unabhängiger Sicherheitsagent prüft Änderungen gezielt kritisch, während der Korrektur und erneut in der Release-Pipeline. Das sind die eigenen Aussagen von AWS zu seinem Verfahren. Eine unabhängige Prüfung liefert der Beitrag nicht.

Grenzen, die man einplanen sollte

Der Beitrag nennt die Grenzen offen. Der Emulator wertet IAM-Richtlinien und ressourcenbasierte Richtlinien nicht so aus wie AWS, deshalb kann eine Anfrage, die AWS ablehnt, lokal gelingen. AWS rät, ihn nicht zu nutzen, um die Sicherheit einer Anwendung zu testen. Jeder Emulator verhält sich wie ein einzelnes Konto, ohne Verhalten zwischen Konten oder Regionen. Wie nah er an AWS liegt, hängt von Dienst und Funktion ab, daher lohnt ein Blick auf die Fidelity-Werte der genutzten Dienste. Standardmäßig sendet er anonyme Nutzungs- und Fehlerdaten, was sich abschalten lässt. Unter dem Beitrag nennt ein Leser in einem einzigen Kommentar unter anderem ein bei jedem Start neu erzeugtes Zertifikat und einen Fehler bei der Speicherung von in Blöcken signierten S3-Uploads des .NET-SDK. Das sind nicht unabhängig geprüfte Nutzerberichte und keine Aussagen von AWS. Bis AWS antwortet, sollte man sie als unbestätigt behandeln.

Was das für Entwickler bedeutet

Für Teams, die heute gegen echte AWS-Konten testen, kann ein ausreichend genauer lokaler Endpunkt Kosten und Wartezeit senken. Er gibt Coding-Agenten außerdem einen sicheren Ort zum Ausprobieren. Der Preis: Ein grüner lokaler Test beweist kein Verhalten in der Produktion, besonders nicht bei Sicherheitsregeln. Halten Sie echte Zugangsdaten aus den Testläufen heraus und führen Sie die Endprüfung vor dem Release auf AWS durch.