AWS Emulator: Free Local AWS Built by AI Agents (HN Review)

Last updated: November 12, 2026 - based on AWS's November 11 launch posts and the aws-emulator README as of today.

AWS has released a free local copy of its own cloud, and the headline is not the emulator. It is that "the emulator was written entirely by autonomous agents" and, in the words of its lead engineer, "our team hasn't written or reviewed any of the code." The "aws emulator" search term went from near zero to the top of its Google Trends chart in two days, with "aws emulator autonomous ai agents" showing as a breakout query. If you test code against SQS, DynamoDB or Lambda in CI, this page covers what shipped, how the agent loop works, and what to verify before you swap it in.

What AWS shipped#

AWS Emulator is a local emulator of the AWS APIs. You run it on your machine, a dev server or in CI, and your SDK talks to it instead of AWS, so there are no AWS resources to pay for and no AWS account is needed. Per the README there are three ways in:

• With a coding agent. Install the aws-emulator skill with aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1 (needs AWS CLI 2.35.0 or later), then ask the agent to set it up.
• Server mode. An RPM or Debian package on Linux, or a container on macOS and Windows. It serves HTTPS on 127.0.0.1:9297 with a self-signed certificate when run from source.
• Embedded mode for Rust tests. The emulator runs in-process, one isolated instance per test, with no endpoint URL or certificate to configure.

Scope, from Swami Sivasubramanian's launch post: built from more than 400 API models covering more than 200 AWS services. The code is CC0 (public domain) except a vendored framework directory under Apache 2.0, and the repository does not take pull requests.

Two honesty notes from the README matter more than the service count. It says AWS Emulator is for building and testing, not for production workloads or security testing. And it ships with telemetry on by default; turn it off with aws-emulator --telemetry off or export EMULATOR_TELEMETRY=off.

How three teams of agents build it#

The interesting part is the recipe in Matt Goldberg's launch post. It started as a weekend experiment. Goldberg, a senior principal engineer, was inspired by Anthropic's C compiler experiment: give agents a well-defined spec and a reference implementation and they can build something faithful to it. For AWS the spec is the public AWS API models and the reference implementation is the real cloud. His first prompt to Kiro had three steps: write tests from the AWS CLI, iterate until they pass against real AWS, then build an in-memory implementation that passes the same tests. Kiro returned a passable SQS in about 15 minutes.

The product version splits the work into three bounded teams:

1. Test writers devise real scenarios (create a queue, send, receive, acknowledge, delete), verify each against real AWS, and save them. AWS says there are tens of thousands of these fidelity tests and they replay without calling AWS again.
2. Issue finders replay the tests against the emulator and file failures, grouped by suspected root cause.
3. Fixers take one issue each and send the fix through a merge gate: build, coding-standards review, security review and a fidelity regression check. A failing change goes back for rework.

AWS reports thousands of issues fixed per day with hundreds of agents working at once. Those are vendor-reported numbers, but the repository backs the shape: the repository page shows 29,684 commits in a project whose first commit was on October 21, and the commit messages carry tags like Producer: issue-finder and Producer: issue-fixer. The issues themselves are public in issues/things-that-do-not-work and issues/things-that-now-work.

The angle: the test oracle is the product#

Read past the "no humans" framing and the engineering lesson is about oracles. The agents are not trusted. The fidelity tests are, because each one was checked against real AWS before it counted. Swami's post makes the same point with a personal story: he supervised an agent rebuilding a replication engine for four nights before noticing it had no way to check its results. Once it had a spec and a test environment, the rebuild took about two hours, against four months the first time (his account).

That is the pattern in our agent harness explainer and the pass/fail oracle write-up: autonomy scales with the strength of the check, not the strength of the model. It also cuts against the failure mode in the fragile-codebase essay, where agents ship code nothing verifies. AWS has the rare luxury of a perfect reference implementation to diff against. Most teams do not, which is why spec-driven workflows lean so hard on writing the spec first.

For builders there is a second effect. A realistic local AWS closes the loop for a coding agent: it can run its own infrastructure code, read the failure and retry without touching a real account. If you already use Kiro or any agent that shells out to the AWS CLI, that is the real product.

What people are actually saying#

The Hacker News thread had about 795 points and 230 comments when I read it. The reaction was interested and skeptical in equal parts.

• Will it be maintained? One commenter said they were wary of building on it because it was not clear whether it was an exercise or a shipping product, and said an existing open-source AWS emulator, Floci used with Testcontainers, had worked well for them. An AWS employee replied in the thread that it is a real product they plan to maintain and pointed to the launch posts. Another commenter answered that a promise on a forum is not a commitment.
• Is 29,684 commits a good sign? A commenter noted that roughly a thousand accepted commits a day does not by itself signal a mature product. That is a fair reading: volume is what the loop produces, not evidence of fidelity.
• Can you trust the simulator? The sharpest question was where accuracy gets guaranteed, given that agent loops miss things. One commenter ran the published per-service scores through a script and posted a table with scores that vary widely across services. Treat that as a user's rough analysis, not an AWS statement.
• Fidelity is the whole game. Another commenter said the thing that matters is running your actual code locally with high behavioral fidelity, and that AWS has to go further than a typical project to get there.

The counter-case in AWS's favor: unlike most "AI wrote it" projects, this one publishes its test corpus and issue backlog, so you can check its claims instead of taking them on faith.

What to do Monday#

1. Check your services first. Open the latest release and read the fidelity scores for the services you actually call, and the README's "Checking whether your project works" guide. A service at low fidelity is a flaky test waiting to happen.
2. Run it beside your current setup, not instead of it. Point a copy of your integration suite at the emulator and diff the results against your existing local stack and a real sandbox account.
3. Turn telemetry off in CI with EMULATOR_TELEMETRY=off.
4. Budget the build if you use embedded mode. The README warns that the first cargo test compiles every service crate, recommends at least 100 GB of free disk for target/ when building from source, and suggests caching target/ and pinning to a release commit.
5. Keep security tests on real AWS. IAM and policy behavior is exactly where the README tells you not to rely on it.

use aws_emulator_embedded::{AwsEmulatorEmbedded, EmbeddedOptions, Telemetry};

let emulator = AwsEmulatorEmbedded::new(EmbeddedOptions::default().telemetry(Telemetry::Off));
let _http_client = emulator.http_client();

That snippet is the README's own embedded-mode example; wire the returned HTTP client into your SDK client as the embedded guide describes.

Continue Reading#

• AWS Kiro developer guide - the agent that wrote the first SQS prototype
• What is an agent harness - the loop and checks around the model
• Agent harness pass/fail oracle - why strong checks make autonomy safe
• Spec-driven agent workflows - writing the spec the agents build against
• AI-generated code and fragile codebases - what happens without the oracle

Sources#

• How we built the agents that built AWS Emulator - Matt Goldberg, AWS, November 11, 2026
• AWS Emulator and the engineer's job when agents write the code - Swami Sivasubramanian, All Things Distributed
• aws/aws-emulator on GitHub - README, issues directory and releases
• Hacker News discussion
• Anthropic: building a C compiler with agents