KI-Modelle und Plattformen
AWS veröffentlicht lokalen Emulator, der vollständig von autonomen KI-Agenten geschrieben wurde
Unite.AI zu deinen bevorzugten Quellen auf Google hinzufügen
AWS veröffentlichte den AWS-Emulator am 11. November 2026. Der allgemein verfügbare lokale Emulator basiert auf 438 AWS-API-Modellen, die mehr als 200 Dienste abdecken. Autonome KI-Agenten haben seinen Code geschrieben und getestet. Dadurch können Entwickler und Programmieragenten AWS-APIs auf ihren eigenen Rechnern ohne AWS-Konto ausprobieren.
Die AWS CLI, AWS SDKs und Coding-Agenten verbinden sich über einen lokalen HTTPS-Endpunkt und verwenden dabei dieselben APIs wie in der Cloud. Umgebungsvariablen leiten diese Tools auf den Rechner des Nutzers um, sodass der Anwendungscode unverändert bleibt. Ein Einführungsbeitrag von AWS beschreibt RPM- und Debian-Pakete für Linux, Docker für macOS und Windows sowie einen eingebetteten Modus für Rust-Tests. Es fällt keine zusätzliche Servicegebühr an, Kunden zahlen jedoch weiterhin für AWS-Ressourcen, die sie in der Cloud bereitstellen.
Für Coding-Agenten bindet der Emulator AWS-Infrastruktur in eine Schreiben-Ausführen-Lesen-Schleife ein: Ein Agent kann eine Ressource erstellen, das Ergebnis prüfen und seinen Code überarbeiten, ohne auf die Bereitstellung in einer AWS-Region warten zu müssen. In der AWS-Dokumentation werden außerdem Entwicklungsserver und kontinuierliche Integration als Einsatzumgebungen für den Emulator genannt. Die Anfragen gehen dabei an emulierte Ressourcen statt an AWS.
Drei Agententeams entwickeln und warten den Code
Matthew Goldberg, leitender Principal Engineer bei AWS, sagte in einem Bericht aus dem Engineering, sein Team habe den Code des Emulators weder geschrieben noch überprüft. Stattdessen schufen Menschen das Gerüst für diese Arbeit, darunter die Spezifikationen, die Testinfrastruktur, die Freigabeschranken für Zusammenführungen und die Release-Pipeline. Das Projekt begann damit, dass der Coding-Agent Kiro auf eine Eingabeaufforderung hin in etwa 15 Minuten einen brauchbaren Amazon-SQS-Emulator erstellte. Die Aufforderung lautete, Tests zu schreiben, sie anhand des echten AWS zu validieren und eine speicherinterne Implementierung zu entwickeln, die diese Tests besteht. Anschließend ließ Goldberg Kiro den Prototyp über ein Wochenende erweitern. Um daraus ein robustes Produkt zu machen, waren die umgebenden Schutzmaßnahmen erforderlich.
Drei klar abgegrenzte Agententeams teilen sich inzwischen die Arbeit. Testautoren entwickeln anhand öffentlicher API-Modelle Testszenarien und überprüfen sie mit echtem AWS. Agenten zur Fehlersuche führen die Tests erneut aus und gruppieren Fehler, die möglicherweise dieselbe Ursache haben; Agenten zur Fehlerbehebung kümmern sich jeweils um ein einzelnes Problem. Goldberg berichtet von Zehntausenden Übereinstimmungstests. Während Hunderte Agenten parallel arbeiten, werden täglich Tausende Probleme behoben.
Jede vorgeschlagene Korrektur muss kompiliert werden und automatisierte Prüfungen zu Codierungsstandards, Sicherheit und Übereinstimmung bestehen, bevor sie zusammengeführt werden kann. Ein unabhängiger Sicherheitsagent prüft Änderungen während der Entwicklung und erneut in der Release-Pipeline auf mögliche Schwachstellen. „Ohne diese Freigabeschranke würden wir dem, was unsere Agenten entwickeln, nicht vertrauen“, schrieb Goldberg.
Anschließend durchlaufen Änderungen AWS CodeCommit und CodePipeline, bevor sie auf GitHub veröffentlicht werden. Das öffentliche Repository enthält den Commit-Verlauf sowie separate Ordner für behobene und noch offene Übereinstimmungsprobleme. AWS veröffentlichte den Code unter CC0, einer Widmung zur Gemeinfreiheit; ausgenommen ist Anbietercode unter Apache 2.0. Das Repository nimmt keine Pull Requests an, Nutzer können Fehler und Abweichungen bei der Übereinstimmung jedoch über GitHub Issues melden.
Übereinstimmungswerte stecken den Rahmen ab
Ein Übereinstimmungstest ist ein kurzer Arbeitsablauf, der mit echtem AWS abgeglichen wird. Damit der Emulator den Test besteht, muss er bei jedem Aufruf dieselbe Antwort liefern – einschließlich Statuscode, Inhalt sowie exaktem Fehlercode und Fehlertext – und außerdem dieselben Ressourcen und Daten erstellen wie der Arbeitsablauf. Nicht implementierte Vorgänge geben HTTP 501 (Not Implemented) zurück, sodass Fehler sofort sichtbar werden. Zu jedem Release gehören die bestandenen Tests pro Dienst. AWS weist darauf hin, dass zusätzliche Tests den Wert senken können, selbst wenn sich der Emulator verbessert.
Jeder Test in der öffentlichen Evaluierungstestsuite wurde anhand von mindestens zwei isolierten AWS-Testkonten überprüft. Im Repository wird außerdem klargestellt, dass das Verhalten ohne entsprechenden Test nicht verifiziert ist.
Diese Werte machen den Emulator nicht zu einer Sicherheits-Testumgebung. Er wertet AWS Identity and Access Management (IAM) oder ressourcenbasierte Richtlinien nicht so aus wie AWS. Daher könnte eine Anfrage, die AWS ablehnt, lokal erfolgreich sein. Der Emulator ist für Entwicklung und Tests vorgesehen; Produktionsworkloads und Anwendungssicherheitstests sind nicht abgedeckt. Jede Instanz ist für ein einzelnes Konto und eine einzelne Region vorgesehen, hält Ressourcen im Arbeitsspeicher und löscht sie beim Beenden.
Der Schwerpunkt der Entwicklungsarbeit verlagert sich auf Spezifikationen und Tests
Im Einführungsbeitrag beschrieb Swaminathan Sivasubramanian die Rolle des Engineers so: Er entscheidet, was entwickelt werden soll, und erstellt die Spezifikationen, Tests und Freigabeschranken, anhand derer die Korrektheit beurteilt wird, während Agenten den Code schreiben und prüfen.
Sein Vergleich mit Alf, einem frühen verteilten Sperrdienst von Amazon, liefert ein konkretes Beispiel. Die ursprüngliche Replikations-Engine benötigte etwa vier Monate Entwicklungszeit. Sivasubramanian zufolge dauerte eine Neuentwicklung mit Kiro zunächst vier überwachte Nächte, weil der Agent seine Ergebnisse nicht überprüfen konnte. Nachdem er eine Spezifikation und eine Testumgebung bereitgestellt hatte, war die Neuentwicklung in etwa zwei Stunden abgeschlossen.
AWS Emulator setzt diese Erkenntnis in einem veröffentlichten Produkt um: Agenten erstellen und reparieren die Implementierung, während Engineers das akzeptable Verhalten definieren und dessen Einhaltung automatisieren. Wie weit sich das Produkt praktisch einsetzen lässt, hängt inzwischen vom Wachstum der öffentlichen Testsuite und den verbleibenden Übereinstimmungslücken ab. Sicherheitsprüfungen und die Validierung für den Produktionseinsatz erfordern weiterhin echtes AWS.
