AWS Emulator Released as Agent-Written Local Tester

Amazon said on 11 November 2026 that it has released AWS Emulator, a local programme that serves AWS API endpoints on a developer’s machine, a development server or in continuous integration. In an Amazon News post published at 17:25 GMT (Europe/London), Matthew Goldberg, a senior principal engineer at AWS, wrote that “the emulator was written entirely by autonomous agents” and that “Our team hasn’t written or reviewed any of the code.” Those are Amazon’s claims about how the code was produced, not an independent audit of the repository.

The official AWS Emulator User Guide describes a narrower product than the headline. AWS Emulator is a local emulator of the AWS APIs. Requests go to the emulator, not to AWS, and an AWS account is not required. “AWS Emulator has no additional service fee. You pay only for AWS resources when you deploy on AWS.” The same guide says the emulator is for building and testing. It is not, on Amazon’s own wording, a tool for production workloads, and it does not evaluate IAM and resource-based policies the way AWS does, so it is also not a stand-in for security testing.

The source is on GitHub under a CC0 1.0 Universal public dedication, which the repository’s LICENSE file and the GitHub licence metadata both record as CC0-1.0. Goldberg said the public dedication followed the insights AWS had gained from watching agents build successive versions of the emulator.

A local endpoint, with published limits

After the emulator is started, the AWS CLI or an AWS SDK is pointed at its endpoint with environment variables, and existing code is run as usual. On Linux it is installed from an RPM or Debian package for x86_64 or aarch64. On Windows and macOS, AWS’s documentation says it should be run in a container built from a short Dockerfile. For tests written in Rust with the AWS SDK for Rust, an embedded mode runs the emulator inside the test process, with a separate state for each instance and no endpoint URL to configure. The public README says a build from source serves HTTPS on 127.0.0.1:9297 with a self-signed certificate.

Amazon is also clear about what the emulator does not do. Resources are kept in memory and are deleted when the emulator stops. It accepts any Region and account ID in a request but does not keep resources separate by Region or account, so the user guide tells people to use one Region and one account per emulator process. Behaviour is checked against AWS in the US West (Oregon) Region, us-west-2, except for global services, which are checked in us-east-1. Differences in regional feature availability are not reflected. AWS says it has not tested the emulator for long-running use or load testing.

Telemetry is on by default. The user guide says the emulator does not send request, response or resource data to AWS, but that it sends anonymous usage and error data, which can be turned off with a command-line flag, an environment variable, a config file, or the embedded API.

Goldberg’s post is more ambitious about the build process than the user guide is about the product. He describes three teams of agents: one writes fidelity tests from publicly released AWS API Models and verifies them against real AWS; one replays those tests against the emulator and files failures; and one fixes a single issue at a time. Fixes, he says, have to pass a merge gate that checks that the change compiles, meets coding standards, “verify the code is secure,” and has not regressed fidelity. He writes that the system first generated “an empty web server that could handle requests for the 438 AWS API Models but did nothing,” and that “We have tens of thousands of fidelity tests across all of AWS.” Those tests, and a separate evaluation-suite repository, are the published measure of how closely each service matches AWS. Individual gaps are tracked in the emulator repository under issues/things-that-do-not-work/, with fixes moved to issues/things-that-now-work/. Fidelity scores are published with each release. That is a large test suite, not a claim of full coverage.

An agent-written emulator is still a test double, not a second AWS

The useful way to read the 11 November release is to keep the authorship claim and the product limits in separate hands. Amazon is asking readers to accept that a substantial emulator of its own APIs was produced by agents, under guardrails, without the team writing or reviewing the code. That statement should stay attributed. The merge gate Goldberg describes includes agents that “verify the code is secure”; it is not the same thing as a human review of the source, and it does not change the user guide’s warning that the emulator is the wrong place to test security.

The closer practical question is fidelity. Tens of thousands of tests, 438 API models and a public issue backlog are a serious attempt to measure divergence from AWS, and the scores published with each release are the document to watch. They also imply unfinished work. A test double that is this large is still a test double. It is most useful where the user guide places it: local testing, CI without an AWS account, and prototyping with coding agents, with the published gaps in view.

That is also why the emulator sits next to, rather than instead of, AWS’s other agent-infrastructure releases. Nitro Sandboxes is a hardware-isolated runtime for agent workloads on EKS, ECS and EC2, which is a production-adjacent isolation story the emulator is explicitly not. Infinity is AWS’s claim about packing idle agents into memory, again a runtime question. The earlier move to make the AI/ML skill a core part of the Agent Toolkit is about how coding agents call AWS, which is one of the jobs the emulator is now meant to support offline. None of those posts is a substitute for the fidelity scores. If later releases close the backlog, or if AWS publishes a human review of the code it currently says it has not reviewed, that would change the story. Until then, AWS Emulator is a CC0 local tester, with no additional service fee, built — Amazon says — entirely by agents, and bounded by the limits in its own documentation.