AWS Ships an Emulator Written Almost Entirely by AI Agents

AWS released a local emulator on November 11, 2026, and almost none of its code was written by humans. The tool, called AWS Emulator, covers more than 200 AWS services through 438 API models. Autonomous AI agents wrote it, tested it, and continue to fix it every day. It lets developers and coding agents exercise AWS APIs on their own machines — with no AWS account and no service fee.

The stakes here go beyond one developer tool. If agents can build and maintain production-quality software while humans supply only specifications and test harnesses, the economics of platform engineering shift toward verification work. AWS just shipped the most concrete evidence yet that this model works at scale.

What does the emulator actually do?

The AWS CLI, AWS SDKs and coding agents connect through a local HTTPS endpoint. They use the same APIs they would use in the cloud. Environment variables redirect those tools to the user's machine, so application code stays unchanged.

AWS ships the emulator as RPM and Debian packages for Linux, Docker images for macOS and Windows, and an embedded mode for Rust tests. There is no additional service fee, though customers still pay for any AWS resources they deploy in the cloud.

For coding agents, the tool closes the loop. An agent can create a resource, inspect the result, and revise its code — all without waiting for a deployment to an AWS Region. AWS documentation also lists development servers and continuous integration as target environments, with requests routed to emulated resources instead of the real cloud.

Who wrote the code?

AWS senior principal engineer Matthew Goldberg said his team neither wrote nor reviewed the emulator's code. Humans built everything around it: the specifications, the test machinery, the merge gates, and the release pipeline.

The project began with a prompt. Goldberg asked the Kiro coding agent to write tests, validate them against real AWS, and build an in-memory implementation that passed them. Kiro produced a passable Amazon SQS emulator in roughly 15 minutes. Goldberg then had Kiro expand the prototype over a weekend. Turning that prototype into a robust product, he said, required the surrounding guardrails.

Three bounded agent teams now divide the ongoing work:

• Test writers devise scenarios from public API models and verify them against real AWS.
• Issue finders replay the tests and group failures that may share a root cause.
• Fixer agents take one issue each.

Goldberg reports tens of thousands of fidelity tests in the suite, with thousands of issues fixed daily as hundreds of agents work concurrently.

How does AWS trust agent-written code?

Every proposed fix must compile and pass automated checks for coding standards, security and fidelity before it can merge. An independent security agent reviews changes adversarially — once during development and again in the release pipeline.

"Without this merge gate, we wouldn't trust what our agents are building," Goldberg wrote.

Changes move through AWS CodeCommit and CodePipeline before publication on GitHub. The public repository exposes the full commit history and separate folders for resolved and unresolved fidelity issues. AWS published the code under CC0, a public-domain dedication, except for vendor code under Apache 2.0. The repository does not accept pull requests, but users can report bugs and fidelity gaps through GitHub Issues.

What are the fidelity scores?

A fidelity test is a short workflow checked against real AWS. To pass, the emulator must match the response to every call — the status code, the body, and the exact error code and message — plus the resources and data the workflow creates. Unimplemented operations return HTTP 501 (Not Implemented), so failures surface immediately.

Each release carries per-service pass counts. AWS cautions that adding tests can lower a score even as the emulator itself improves. Every test in the public evaluation suite was verified against at least two sandboxed AWS accounts. The repository states plainly that behavior without a test is not verified.

Can you use it for security testing?

No. The emulator does not evaluate AWS Identity and Access Management (IAM) or resource-based policies the way AWS does. A request AWS would deny could succeed locally. AWS defines the supported use as building and testing; production workloads and application security tests are out of scope. Each instance is intended for one account and one Region, keeps resources in memory, and deletes them when stopped.

What happens to the engineer's job?

In the launch post, Swaminathan Sivasubramanian described the engineer's new role: deciding what should be built and creating the specifications, tests and merge gates that determine correctness, while agents write and check the code.

He offered a concrete yardstick. Alf, an early Amazon distributed lock service, took about four months to build its original replication engine. A Kiro rebuild first consumed four supervised nights, because the agent had no way to check its results. After Sivasubramanian provided a specification and test environment, the rebuild took about two hours.

That gap — four months, four nights, two hours — is the real story inside AWS Emulator. Agents generate and repair the implementation; engineers define acceptable behavior and automate its enforcement. The practical reach of the tool now depends on the growing public test suite and the remaining fidelity gaps, and security or production validation still requires real AWS.