AWS Ships Emulator Built Entirely by Autonomous AI Agents

AWS released a generally available local emulator on November 11, 2026, and no human being wrote its code. Autonomous AI agents wrote and tested the entire product — AWS Emulator — which covers more than 200 services through 438 AWS API models and lets developers exercise AWS APIs on their own machines without an AWS account.

The tool targets a precise problem: testing AWS integrations costs time and cloud spend. The AWS CLI, AWS SDKs and coding agents connect through a local HTTPS endpoint using the same APIs they would call in the cloud. Environment variables redirect those tools to the user's machine. Application code stays unchanged. An AWS launch post details RPM and Debian packages for Linux, Docker on macOS and Windows, and an embedded mode for Rust tests. There is no additional service fee, although customers still pay for AWS resources they deploy in the cloud.

For coding agents, the emulator puts AWS infrastructure inside a write-run-read loop. An agent can create a resource, inspect the result and revise its code without waiting for deployment to an AWS Region. The AWS documentation also lists development servers and continuous integration as target environments, with requests routed to emulated resources rather than AWS.

Who actually wrote the code?

AWS senior principal engineer Matthew Goldberg said in an engineering account that his team neither wrote nor reviewed the emulator's code. Humans built the scaffolding instead: the specifications, test machinery, merge gates and release pipeline.

The project started small. The Kiro coding agent produced a passable Amazon SQS emulator in about 15 minutes from a single prompt: write tests, validate them against real AWS, and build an in-memory implementation that passed them. Goldberg then had Kiro expand the prototype over a weekend. Turning it into a robust product required the surrounding guardrails.

Three bounded agent teams now divide the 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, with thousands of issues fixed daily as hundreds of agents work concurrently. Every proposed fix must compile and pass automated checks for coding standards, security and fidelity before merging. An independent security agent reviews changes adversarially 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 commit history and separate folders for resolved and unresolved fidelity issues. AWS published the code under CC0, a public-domain dedication, except vendor code under Apache 2.0. The repository does not accept pull requests, though users can report bugs and fidelity gaps through GitHub Issues.

What do fidelity scores actually measure?

A fidelity test is a short workflow checked against real AWS. To pass, the emulator must match the response to every call: status code, body, 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, and AWS cautions that adding tests can lower a score even as the emulator 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.

The scores do not make the emulator a security test environment. It does not evaluate AWS Identity and Access Management or resource-based policies the way AWS does. A request AWS denies could succeed locally. The supported use is building and testing; production workloads and application security tests sit out of scope. Each instance serves one account and Region, keeps resources in memory and deletes them when stopped.

How does this change engineering work?

In the launch post, Swaminathan Sivasubramanian described the engineer's role as 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 comparison: Alf, an early Amazon distributed lock service. Its original replication engine took about four months to build. A Kiro rebuild first consumed four supervised nights because the agent had no way to check its results. After he provided a specification and test environment, the rebuild took about two hours.

AWS Emulator turns that lesson into a shipped product: agents generate and repair the implementation, while engineers define acceptable behavior and automate its enforcement. Its practical reach now depends on the growing public test suite and remaining fidelity gaps — with security and production validation still requiring real AWS.