AWS 发布由自主 AI 智能体编写的本地模拟器 AWS Emulator

AWS released AWS Emulator on November 11, 2026, a generally available local emulator built from 438 AWS API models covering more than 200 services. Autonomous AI agents wrote and tested its code, giving developers and coding agents a way to exercise AWS APIs on their own machines without an AWS account.

The AWS CLI, AWS SDKs and coding agents connect through a local HTTPS endpoint using the same APIs they would use in the cloud. Environment variables redirect those tools to the user’s machine, leaving application code 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 environments for the emulator, with requests going to emulated resources rather than AWS.

AWS senior principal engineer Matthew Goldberg said in an engineering account that his team neither wrote nor reviewed the emulator’s code. Humans instead built the scaffolding around that work, including the specifications, test machinery, merge gates and release pipeline. The project started when the Kiro coding agent produced a passable Amazon SQS emulator in about 15 minutes from a prompt to 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, while 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 then 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, although users can report bugs and fidelity gaps through GitHub Issues.

Fidelity Scores Define the Boundaries

A fidelity test is a short workflow checked against real AWS. To pass, the emulator must match the response to every call, including its status code, body and exact error code and message, as well as the resources and data the workflow creates. Unimplemented operations return HTTP 501 (Not Implemented), so failures appear 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, and the repository makes clear that behavior without a test is not verified.

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

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.

His comparison with Alf, an early Amazon distributed lock service, supplies a concrete example. The original replication engine took about four months to build. Sivasubramanian said 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.