Von Daniel Abib am 11. November 2026 in Amazon Bedrock AgentCore, Ankündigungen, Entwicklertools, Launch, Technische Anleitung – Permalink – Kommentare – Teilen
Heute kündigen wir den AWS Emulator an, einen lokalen Emulator für Amazon Web Services (AWS), den Sie auf Ihrem Rechner ausführen. Die AWS Command Line Interface (AWS CLI), die AWS SDKs und Ihre Coding-Agents kommunizieren mit ihm über einen lokalen HTTPS-Endpunkt und verwenden dabei dieselben AWS-APIs wie in der Cloud – direkt von Ihrem Laptop aus. Für den AWS Emulator fällt keine zusätzliche Servicegebühr an. Sie zahlen nur für AWS-Ressourcen, wenn Sie auf AWS bereitstellen. Der Quellcode ist auf GitHub verfügbar. Sie installieren ihn unter Linux über ein RPM- oder Debian-Paket, auf macOS und Windows führen Sie ihn in Docker aus.
So funktioniert es
Sie installieren den Emulator, starten ihn und richten Ihre Tools auf den lokalen Endpunkt aus. Beim Start generiert der AWS Emulator eigene Anmeldedaten, eine Konfigurationsdatei und ein Zertifikat und schreibt sie nach ~/.aws/emulator/9297/. Sie setzen Umgebungsvariablen, damit das AWS SDK mit Ihrem Laptop statt mit AWS kommuniziert – Ihr Anwendungscode bleibt unverändert.
Von da an funktionieren Ihre vorhandenen Tests, CLI-Skripte und Coding-Agents genau wie bisher. Ein Unit-Test, der eine Amazon-DynamoDB-Tabelle erstellt, ein Element schreibt und es wieder liest, ist derselbe Test – und er läuft auf Ihrem Rechner ohne Bereitstellung. Ein Coding-Agent kann Ressourcen erstellen, das Ergebnis prüfen und erneut iterieren, ohne auf eine Bereitstellung in einer Region warten zu müssen.
Der Emulator ist in Rust implementiert, damit er auf einem Laptop wenig CPU und Arbeitsspeicher beansprucht. Er unterstützt die APIs der AWS-Dienste, die ein API-Modell im AWS-API-Models-Repository auf GitHub haben. Da er auf diesen Modellen aufbaut – denselben, die auch die AWS SDKs verwenden –, haben Ihre Anfragen und die zurückgegebenen Fehler dieselbe Struktur wie auf AWS.
Wenn Sie Entwickler sind – insbesondere wenn Sie mit Coding-Agents wie Kiro oder Claude Code arbeiten –, können Sie diese Schleife nutzen, um AWS-Interaktionen von echter Komplexität lokal zu testen.
Probieren wir es aus
Zum Einstieg habe ich das Paket auf Amazon Linux 2023 installiert. Das Paket fügt den Befehl aws-emulator zu /usr/bin/ hinzu, sodass er im Pfad verfügbar ist.
PKG=https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest
sudo dnf install -y $PKG/aws-emulator-x86_64.rpm
aws-emulator -vAuf macOS und Windows erstellen Sie ein Docker-Image aus dem kurzen Dockerfile in der Dokumentation und führen den Emulator in einem Container aus. Wir veröffentlichen kein fertiges Image.
Ich habe den Emulator mit aws-emulator gestartet. Er stellt HTTPS auf 127.0.0.1:9297 bereit, sodass nur mein eigener Computer darauf zugreifen kann, und schreibt sein Protokoll als JSON-Zeilen, die die Adresse, die Konfigurationsdatei und die Zertifikatsdatei anzeigen.
aws-emulatorIn einem anderen Terminal habe ich die Umgebungsvariablen gesetzt, die die AWS CLI auf den Emulator ausrichten, und alle Variablen entfernt, die echte AWS-Anmeldedaten liefern könnten.
export AWS_ENDPOINT_URL=https://127.0.0.1:9297
export AWS_SHARED_CREDENTIALS_FILE=~/.aws/emulator/9297/emulator_credentials
export AWS_CONFIG_FILE=~/.aws/emulator/9297/config
export AWS_EC2_METADATA_DISABLED=true
export AWS_DISABLE_HOST_PREFIX_INJECTION=true
export AWS_REGION=us-east-1
export AWS_DEFAULT_REGION=us-east-1
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILEDer Emulator generiert bei jedem Start neue Schlüssel. Die Zugriffsschlüssel-IDs beginnen mit EMULATOR, sodass Sie sie nicht mit echten AWS-Schlüsseln verwechseln können, und er lehnt Anfragen ab, die mit anderen Schlüsseln signiert sind. Um zu bestätigen, dass meine Shell mit dem Emulator kommunizierte, habe ich den Health-Endpunkt und die Aufruferidentität überprüft. Der Emulator verwendet ein einziges Konto: 000000000000.
curl --cacert ~/.aws/emulator/9297/ca.pem https://127.0.0.1:9297/__admin/health
aws sts get-caller-identityDann habe ich einen Bucket erstellt, ein kleines Objekt hineinkopiert und es aufgelistet.
$ aws s3 mb s3://local-getting-started
make_bucket: local-getting-started
$ echo "hello from the emulator" > hello.txt
$ aws s3 cp hello.txt s3://local-getting-started/
upload: ./hello.txt to s3://local-getting-started/hello.txt
$ aws s3 ls s3://local-getting-started/Mit der auf meinen Laptop ausgerichteten AWS CLI hatte ich dieselben Befehle, die ich bereits verwende – und einen lokalen Endpunkt, der sie beantwortete.
Als Nächstes wollte ich es so sehen, wie ich heute tatsächlich arbeite. Also öffnete ich bei weiterhin laufendem Emulator Kiro und bat es, eine Amazon-DynamoDB-Tabelle zu erstellen, ein Element zu schreiben und es wieder zu lesen – alles gegen den AWS Emulator statt gegen mein AWS-Konto.
kiro> Using the local AWS Emulator (the environment variables
are already set in this shell), create a DynamoDB table
"kiro-demo" with a string key "id", put an item
{id: "item-1", msg: "hello from kiro"}, then read it
back with get-item.
$ aws dynamodb create-table --table-name kiro-demo \
--attribute-definitions AttributeName=id,AttributeType=S \
--key-schema AttributeName=id,KeyType=HASH \
--billing-mode PAY_PER_REQUEST
$ aws dynamodb put-item --table-name kiro-demo \
--item '{"id": {"S": "item-1"}, "msg": {"S": "hello from kiro"}}'
$ aws dynamodb get-item --table-name kiro-demo --key '{"id": {"S": "item-1"}}'Um dasselbe Setup mit einer vorhandenen Testsuite zu verwenden, würde ich den Emulator starten, dieselben Umgebungsvariablen im Skript setzen, das die Tests ausführt, und die Tests wie gewohnt laufen lassen.
Den Emulator im Prozess verwenden
Wenn Sie den Emulator als lokalen Prozess ausführen, erhalten Sie einen HTTPS-Endpunkt, der über Umgebungsvariablen mit der AWS CLI und den AWS SDKs funktioniert. Einige SDKs benötigen eine zusätzliche Einstellung, um dem Emulator-Zertifikat zu vertrauen – zum Beispiel einen Trust-Store für das AWS SDK für Java. Für Tests gibt es eine zweite Option. Der AWS Emulator bietet einen eingebetteten Modus, den Sie direkt in Ihrem Testprozess instanziieren und über dessen HTTP-Client mit dem SDK verbinden, statt mit einem separaten Server über das Netzwerk zu kommunizieren. Jede eingebettete Instanz behält ihren eigenen Zustand, sodass Tests keine Buckets, Tabellen oder Warteschlangen gemeinsam nutzen und Sie viele davon parallel ausführen können. Der eingebettete Modus ist für das AWS SDK für Rust verfügbar. Sie fügen die Crate aws-emulator-embedded von GitHub zum Abschnitt [dev-dependencies] Ihrer Cargo.toml-Datei hinzu. Das folgende Beispiel erstellt eine Amazon-DynamoDB-Tabelle, schreibt ein Element und liest es wieder – vollständig im Prozess.
use aws_emulator_embedded::{AwsEmulatorEmbedded, EmbeddedOptions};
use aws_sdk_dynamodb::types::{
AttributeDefinition, AttributeValue, BillingMode, KeySchemaElement, KeyType,
ScalarAttributeType,
};
#[tokio::test]
async fn put_then_get_returns_the_item() {
let emulator = AwsEmulatorEmbedded::new(EmbeddedOptions::default());
let config = aws_config::defaults(aws_config::BehaviorVersion::latest())
.http_client(emulator.http_client())
.region(aws_config::Region::new("us-east-1"))
.credentials_provider(emulator.aws_credentials_provider())
.load()
.await;
let ddb = aws_sdk_dynamodb::Client::new(&config);
ddb.create_table()
.table_name("emulator-demo-table")
.attribute_definitions(
AttributeDefinition::builder()
.attribute_name("id").attribute_type(ScalarAttributeType::S)
.build().unwrap())
.key_schema(
KeySchemaElement::builder()
.attribute_name("id").key_type(KeyType::Hash)
.build().unwrap())
.billing_mode(BillingMode::PayPerRequest)
.send().await.unwrap();
ddb.put_item()
.table_name("emulator-demo-table")
.item("id", AttributeValue::S("item-1".into()))
.item("msg", AttributeValue::S("hi".into()))
.send().await.unwrap();
let got = ddb.get_item()
.table_name("emulator-demo-table")
.key("id", AttributeValue::S("item-1".into()))
.send().await.unwrap();
assert_eq!(got.item().unwrap().get("msg").unwrap().as_s().unwrap(), "hi");
}Wenn er als lokaler Prozess läuft, verlangt der Emulator, dass jede Anfrage mit Signature Version 4 (SigV4) signiert wird – genau wie AWS –, und er stellt einen /__admin/health-Endpunkt auf demselben Port bereit, damit ein Skript oder Container warten kann, bis er bereit ist, bevor Tests ausgeführt werden. Standardmäßig sendet er außerdem anonyme Nutzungs- und Fehlerdaten; Sie können dies deaktivieren.
Wie wir die Genauigkeit messen
Ein Emulator ist nur dann nützlich, wenn ein Test, der gegen ihn besteht, auch gegen AWS bestehen würde. Deshalb messen wir das direkt mit Fidelity-Tests. Ein Fidelity-Test ist ein kurzes Programm, das ein AWS SDK verwendet, um einen Workflow auszuführen – etwa ein Objekt zu speichern, zu lesen und zu löschen – und das Verhalten von AWS zu prüfen. Wir verifizieren jeden Fidelity-Test gegen echtes AWS. Ein Fidelity-Test besteht nur, wenn der Emulator bei der Antwort auf jeden Aufruf mit AWS übereinstimmt: Statuscode, Body, exakter Fehlercode und Fehlermeldung sowie die vom Workflow erstellten Ressourcen und Daten.
Mit jeder Version veröffentlichen wir, wie viele Fidelity-Tests für jeden Dienst bestehen, als k von n. Beispielsweise bedeutet 40 von 50, dass 40 der 50 Fidelity-Tests des Dienstes bestehen. Die Sammlung der Fidelity-Tests ist öffentlich im Repository aws-emulator-evaluation-suite auf GitHub – einschließlich der Tests, die noch nicht bestehen –, sodass Sie sehen können, was wir verifiziert haben, und die Fidelity-Tests selbst ausführen können. Lesen Sie einen Wert als Momentaufnahme eines Produkts, das sich verbessert. Wenn wir Fidelity-Tests hinzufügen, kann ein Wert sinken, obwohl der Emulator besser wird.
Wenn der Emulator eine Operation noch nicht implementiert hat, gibt er HTTP 501 (Not Implemented) zurück, sodass Ihre Tests sofort fehlschlagen. Wenn sich der Emulator anders verhält als AWS, können Sie uns dies mitteilen, indem Sie ein Issue im AWS-Emulator-Repository auf GitHub eröffnen.
Wie der Emulator gebaut wird
Der AWS Emulator wird von Agents aus den AWS-API-Modellen mithilfe von Amazon Bedrock AgentCore Runtime Instances, AWS CodePipeline und AWS CodeCommit erstellt und gepflegt. So bleibt er aktuell, wenn sich diese Modelle ändern.
Eine Gruppe von Agents sucht nach Lücken, indem sie die Emulator-Antworten mit echtem AWS vergleicht und den Emulator-Code statisch mit den veröffentlichten Smithy-Modellen abgleicht. Für jede gefundene Lücke wird ein Issue angelegt. Eine andere Gruppe nimmt sich ein Issue vor, schreibt Tests, implementiert das Verhalten und prüft die Änderung auf Korrektheit, Leistung und Sicherheit. Wenn die Änderung bereit ist, wird sie in ein Quell-Repository gepusht. Dieser Push löst einen AWS-CodePipeline-Lauf aus, der die Fidelity-Tests ausführt, bevor die Änderung im öffentlichen GitHub-Repository veröffentlicht wird.
Wie wir die Sicherheit gewährleisten
Da der Code von Agents geschrieben wird, prüft ein unabhängiger Sicherheits-Agent Änderungen kontradiktorisch – sowohl während der Erstellung des Fixes als auch erneut in der Release-Pipeline als letzte Prüfung vor der Veröffentlichung.
Die Sicherheit Ihrer eigenen Nutzung bleibt eine gemeinsame Verantwortung. Wir bauen den Emulator so, dass er sicher auf Ihrem Rechner läuft: Er hört standardmäßig nur auf Ihrem eigenen Computer und lehnt Anfragen ab, die nicht mit seinen eigenen Schlüsseln signiert sind. Sie entscheiden, wo er läuft, welche Daten Sie hineingeben und wie Sie vor der Produktion testen. Verwenden Sie den Emulator nicht, um zu testen, ob Ihre Anwendung sicher ist. Er bewertet AWS Identity and Access Management (IAM)-Richtlinien und ressourcenbasierte Richtlinien nicht so wie AWS – eine Anfrage, die AWS ablehnt, könnte im Emulator erfolgreich sein. Halten Sie echte Anmeldedaten aus der Umgebung Ihrer Testjobs fern und testen Sie Ihre Sicherheitseinstellungen und Ihre gesamte Anwendung auf AWS, bevor Sie in Produktion gehen.
Jetzt verfügbar
Der AWS Emulator ist ab heute allgemein verfügbar. Es fällt keine zusätzliche Servicegebühr an. Sie zahlen nur für AWS-Ressourcen, wenn Sie auf AWS bereitstellen. Sie können ihn unter Linux über RPM- oder Debian-Pakete installieren, unter macOS und Windows in Docker ausführen oder aus dem Quellcode bauen. Er funktioniert mit den AWS SDKs und der AWS CLI, sobald Sie Umgebungsvariablen gesetzt haben. Beim Start gibt es einige Einschränkungen: Er bewertet IAM-Richtlinien nicht so wie AWS, und jeder Emulator agiert als ein einzelnes Konto ohne konten- oder regionsübergreifendes Verhalten. Wie genau er AWS entspricht, variiert je nach Dienst und Funktion. Um zu sehen, wie gut der Emulator die von Ihnen genutzten Dienste abdeckt, prüfen Sie die Fidelity-Werte in der AWS-Emulator-Dokumentation.
Wenn Sie die regionale Verfügbarkeit prüfen möchten, besuchen Sie die Seite „AWS Capabilities by Region“ im AWS Builder Center. Wenn Sie APIs aufrufen, Dokumentation durchsuchen, regionale Verfügbarkeit finden und Fehlerbehebung zu diesem neuen Feature prüfen möchten, versuchen Sie es mit dem AWS MCP Server und Plugins in Ihrem bevorzugten KI-Tool.
Um loszulegen, lesen Sie die AWS-Emulator-Dokumentation.
Daniel Abib ist Senior Specialist Solutions Architect bei AWS mit Schwerpunkt auf generativer KI und Amazon Bedrock – und begeistert sich für Serverless. Er unterstützt Start-ups und Unternehmen beim Aufbau KI-gestützter Anwendungen und bei der Modernisierung mit cloudnativen Architekturen. Als dreifacher Ironman-Finisher und vierfacher re:Invent-Speaker bringt er dieselbe Ausdauer-Mentalität in die Entwicklung von Cloud-Lösungen ein.
Kommentare werden geladen…