A small metal aircraft model on a sting inside a wind tunnel

AWS shipped a local stand-in for its APIs — and says agents wrote the code

On November 11, AWS announced AWS Emulator, a local stand-in for its APIs. The AWS CLI, the SDKs, and your coding agents talk to it over a local HTTPS endpoint using the same APIs they would use in the cloud, the company says — from your laptop, with no deployment and no AWS account required.

That’s a useful testing story on its own. The unusual part is how AWS says the emulator was made. The News Blog says it is built and maintained by agents, from the published AWS API models. In a companion About Amazon post, Senior Principal Engineer Matthew Goldberg writes that “the emulator was written entirely by autonomous agents” and that “our team hasn’t written or reviewed any of the code.” That’s AWS’s description. I haven’t audited the repository to confirm it.

Cream-paper schematic: a CLI card and a coding-agent card talk to a local emulator process with an in-memory store; a gap marks unimplemented APIs; the path to a remote cloud is broken
The CLI and a coding agent point at a local stand-in, not at the cloud. A gap in the box is a reminder that some APIs still aren’t there. Original schematic by Tech & AI Pulse.

What AWS says you can do with it

You install the emulator, start it, and point your tools at the local endpoint. The News Blog says it listens on your own computer by default, generates its own credentials and a certificate, and rejects requests that aren’t signed with those keys. Access key IDs start with EMULATOR, so they’re harder to confuse with real AWS keys. On Linux you install an RPM or Debian package; on macOS and Windows you run it in Docker. AWS says it does not publish a ready-made image.

From there, existing tests, CLI scripts, and coding agents are supposed to keep working the way they already do. A coding agent can create resources, check the result, and iterate without waiting on a deployment in a Region, the blog says. There’s also an embedded mode for the AWS SDK for Rust, so tests can run the emulator in-process with isolated state. The What’s New post says each copy you start gets its own port, keys, and in-memory state, and that this state lasts until you stop the process.

Fidelity, gaps, and claims I’d keep in that column

For the operations it supports, AWS says the emulator returns the same result as AWS for valid calls and the same errors for invalid ones. Operations it doesn’t support yet return HTTP 501. Fidelity is measured with tests that are first verified against real AWS; each release publishes a score per service, as k of n. The company notes that a score can go down when new tests are added, even if the emulator is improving. Those scores, and the tests that don’t pass yet, are on GitHub for you to read — I wouldn’t treat “same shape as AWS” as a blanket match.

Goldberg describes three teams of agents — one managing a fidelity-test suite, one finding gaps, one fixing them — and a merge gate that also uses agents to review standards, security, and fidelity before a change lands. He writes that they’ve seen thousands of issues fixed every day as hundreds of agents work on the codebase. Those figures are his account, not numbers I measured. The source is published under the CC0 1.0 Universal public domain dedication, according to the What’s New post.

What I wouldn’t assume from “it runs on your machine”

AWS is explicit about two limits that matter more than the marketing. Don’t use the emulator to test whether your application is secure: it doesn’t evaluate IAM policies and resource-based policies the way AWS does, so a request AWS would deny might succeed in the emulator. And don’t use it for production. Each emulator acts as a single account, with no cross-account or cross-Region behavior.

The News Blog also says that by default the process sends anonymous usage and error data, which you can turn off. Requests for your APIs go to the local endpoint, not to AWS — that’s the company’s wording. I wouldn’t stretch that into a promise that nothing ever leaves your machine.

What I’d check before leaning on it

  • Read the fidelity score for the services you actually call. A passing unit test against the emulator is only as useful as the k of n behind those APIs, plus whatever still returns 501.
  • Keep real credentials out of the test environment. AWS says to do this, and to test your security settings on AWS before production.
  • Decide about telemetry up front. The default is on; the off switch is documented.
  • Treat “agents wrote every line” as a claim to inspect, not a result I’ve verified. The interesting artifact is the public issue list — issues/things-that-do-not-work versus things-that-now-work — and the merge-gate description, not the headline.

If you already let a coding agent poke at AWS and you’re tired of waiting on a deploy just to find a bad API call, that’s the part I’d actually test: point the same commands at the local endpoint, and see whether the gaps you hit are ones the fidelity report already warned you about.

AWS says AWS Emulator is generally available. Documentation: AWS Emulator User Guide. Source: github.com/aws/aws-emulator.

Hero photo: a wind-tunnel model in the Abe Silverstein Supersonic Wind Tunnel by NASA on The Commons, via Wikimedia Commons; no known copyright restrictions (Flickr Commons); cropped and resized.