AWS Emulator: a free local copy of 200+ AWS services whose code no human wrote or reviewed

On November 11, AWS made AWS Emulator generally available: a local server that answers the AWS APIs for more than 200 services, with no AWS account and no fee. The product is useful on its own. The reason it drew attention is the claim attached to it. Matthew Goldberg, the AWS senior principal engineer behind it, says his team neither wrote nor reviewed any of the code. Agents did both, and the public repository shows roughly 29,700 commits on main. It is the largest production codebase a major vendor has shipped on those terms, and AWS has published enough of the machinery to judge how it was done.

What you get

AWS Emulator is written in Rust, with one crate per service, generated from 438 of AWS’s public API models. It runs three ways:

• Server mode on Linux, installed from an RPM or Debian package.
• Docker on macOS and Windows, built from a Dockerfile in the docs (no prebuilt image is published).
• Embedded mode, as the aws-emulator-embedded Rust dev-dependency, where each test gets an isolated in-process instance and tests can run in parallel.

Started with aws-emulator, it listens on https://127.0.0.1:9297 with a self-signed certificate and writes credentials, a config file and a CA certificate to ~/.aws/emulator/9297/. You point existing tools at it with environment variables rather than code changes:

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_REGION=us-east-1

AWS also tells you to unset AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN and AWS_PROFILE so real credentials cannot leak into a local run. Requests must be SigV4-signed with the emulator’s own keys, the caller identity is the single account 000000000000, state lives in memory and disappears when the process stops, and any operation that is not implemented returns HTTP 501 instead of a plausible fake.

The pitch to coding agents is explicit. The launch post demonstrates Kiro creating a DynamoDB table and reading an item back, and names Claude Code as a supported client. An agent can create a resource, inspect the result and revise its code in a loop measured in milliseconds instead of waiting on a Region deployment and paying for it.

How agents built it without a human reading the code

The construction method is the part other teams can borrow. According to Goldberg’s account, relayed in Unite.AI’s coverage and the launch post, the project began when Kiro produced a prototype SQS emulator in about 15 minutes. Expanding it over a weekend showed that scale needed guardrails, not better prompts. The resulting system has three bounded teams of agents running on Amazon Bedrock AgentCore:

1. Test writers read the public API models, write short workflow scenarios, run them against real AWS, and save the verified behavior for replay. Every test in the public suite was checked against at least two sandboxed AWS accounts.
2. Issue finders replay those tests against the emulator and group failures that look like they share a root cause.
3. Fixers each take exactly one issue.

A fix merges only if it compiles and passes automated gates for coding standards, security and fidelity regression. A separate security agent reviews changes adversarially during development and again in the release pipeline. Code flows through AWS CodeCommit and CodePipeline before it is published to GitHub. Goldberg reports tens of thousands of fidelity tests, with hundreds of concurrent agents fixing thousands of issues a day, and he is direct about what carries the weight: “Without this merge gate, we wouldn’t trust what our agents are building.”

What makes this workable is not a property of the model. It is that the problem comes with a perfect oracle. The specification is machine-readable, and the reference implementation, AWS itself, can be queried for the right answer to any test: status code, response body, error code, error message, and the resources left behind. Humans wrote the specifications, the test machinery, the merge gates and the release pipeline, and then stayed out of the diff.

AWS’s Swaminathan Sivasubramanian draws the same lesson from a second example. A Kiro rebuild of Alf, an early Amazon distributed lock service, first took four supervised nights because the agent had no way to check its own results. Given a specification and a test environment, the rebuild took about two hours. The original replication engine took about four months. In his framing, the engineer’s job becomes deciding what to build and defining, in executable form, what correct means.

Where the fidelity stops

AWS’s own documentation draws hard lines, and they matter more than the service count.

• IAM is not enforced the way AWS enforces it. The emulator does not evaluate IAM or resource-based policies like the real service, so a request AWS would deny can succeed locally. AWS says plainly not to use it for security testing.
• One account, one Region. There is no cross-account or cross-Region behavior, which rules out testing replication, cross-account roles and multi-Region failover.
• Fidelity varies by service. Each release publishes per-service scores as “k of n” tests passing. AWS warns that a score can fall while the emulator improves, because new tests are added faster than fixes. Behavior that has no test is not verified at all.
• It is for building and testing, not production.

A few operational details are easy to miss. Telemetry (anonymous usage and error data) is on by default; turn it off with --telemetry off or EMULATOR_TELEMETRY=off, which you will want in CI. Building from source needs at least 100 GB of disk. And although the code is CC0, a public-domain dedication (vendored code is Apache 2.0), the repository does not accept pull requests. You can file an issue describing the service, operation, SDK version and how the response differed from AWS, and an agent will pick it up.

Early reaction on Hacker News, summarized by Developers Digest, was mixed in a specific way: nobody disputed that it runs, but commenters pointed out that commit volume is not evidence of fidelity, that per-service scores vary widely, and that long-term maintenance by agents is unproven. An AWS employee replied that it is a real product AWS intends to maintain. The repository keeps its known gaps in public directories (things-that-do-not-work/ and things-that-now-work/), so those claims are at least checkable.

What it means and what to watch

For local AWS development, a free first-party emulator puts pressure on the existing tools in this space, LocalStack above all. The realistic near-term use is alongside your current setup: check the published score for the specific services and operations you call, run the emulator next to a real sandbox account for a while, and keep IAM and policy tests on real AWS.

For teams thinking about agent-written code more broadly, the transferable part is narrow and worth stating precisely. AWS did not show that unreviewed agent code is safe in general. It showed that when you have a machine-readable spec and an authoritative reference to diff against, review can move from the code to the gates. Most application code has neither. The work, if you want this pattern, is building the oracle.

Things to watch over the next few months:

• The per-service scores over successive releases, especially for the services people actually test locally: S3, DynamoDB, Lambda, SQS and Step Functions.
• A defect that the gates missed. The first serious bug report, and how quickly the agent loop closes it, will say more about the model than the launch numbers.
• Whether AWS applies the same approach to code that customers run in production, where there is no real cloud to diff against and the oracle has to be written by hand.