# AWS Emulator: an agent-built local AWS endpoint from 400+ API models

> AWS has shipped a local emulator of its APIs that needs no account and charges no fee. For agent-written infrastructure code, the open questions are fidelity per service and the cost of running it in CI.

- Published: 2026-11-11
- By: Samir Sengupta (https://www.samcodeman.com/about)
- Canonical: https://www.samcodeman.com/writing/aws-emulator-200-services-local-ci-testing
- How this was made: Drafted with Claude, Anthropic's model from 2 cited sources, then checked against them in a second editing pass. Editorial policy: https://www.samcodeman.com/editorial-policy
- Disclosure: I build Wayne, an AI coding harness for VS Code, and Omnitron, an agent harness, so I work in this category.

## The short version

- AWS Emulator is a local AWS API endpoint that needs no AWS account and has no additional service fee. AWS scopes it to building and testing, not production workloads or security testing.
- Agents built it from more than 400 Smithy API models. Fidelity is defined by tests that are corrected until they pass against real AWS, and per-service fidelity scores ship with each release, but the sources quote none of those scores.
- Embedded Rust mode and source builds need at least 100 GB of free disk for target/. The README recommends pinning a release commit and caching target/ or using sccache in CI.
- Neither AWS source mentions LocalStack. The only comparisons come from Hacker News commenters.

AWS released AWS Emulator on November 11, 2026. It is a local emulator of the AWS APIs that runs as a server on Linux, in a Docker container on Windows and macOS, or embedded in Rust tests. It needs no AWS account and has no additional service fee. Agents wrote it from more than 400 Smithy API models covering more than 200 AWS services. Fidelity scores are published per service with each release, but the launch sources do not quote any of them and contain no comparison with LocalStack.

According to the README, the emulator is a program with no graphical interface that serves an AWS API endpoint. You point the AWS CLI or an AWS SDK at it through environment variables, and requests go to emulated resources instead of AWS. At launch the GitHub repository showed 29,684 commits and 1.9k stars. It is licensed under CC0 1.0, except the code in vendor/, which is under the Apache License 2.0.

> Don’t use it for production workloads or to test security.
>
> - AWS Emulator README, github.com/aws/aws-emulator

## Which AWS services does the emulator cover?

Swami Sivasubramanian's guest post on All Things Distributed credits the build method to Matt Goldberg, a Senior Principal Engineer on the AWS Developer Tools team. Goldberg's hypothesis was that an agent could build a working version of a service if it had two inputs: a written description of how the service should behave, meaning the public Smithy API models, and the real service to check against. He started with Amazon SQS alone. One prompt to Kiro returned a passable first version of an SQS emulator in about 15 minutes. The post says the finished emulator is built from more than 400 API models covering more than 200 AWS services. The source text is cut off after '200 AWS', and 'services' is inferred from the post's earlier statement that AWS has over 200 services.

The repository has one crate per AWS service under services/. Each crate holds the Smithy model that drives the wire protocol, the service's in-memory state, and one file per operation. A router crate mounts every service on a single endpoint. The sources do not include a per-service or per-API coverage list. Apart from SQS, they name S3 and DynamoDB only as services that depend on Amazon's internal lock service, Alf, not as services the emulator covers. To check a specific project, the README links to a guide titled Checking whether your project works with AWS Emulator, whose contents are not in the sources.

## Fidelity is defined by tests against real AWS

The agents work from fidelity tests, which are end-to-end customer scenarios devised from the public API models. The guest post gives an example from SQS: a received message stays hidden from other readers until its visibility timeout runs out. The agents correct each test until it passes against real AWS, so the test records how AWS behaves. They then build the emulator until it passes the same test. A test that still fails points at a gap in the emulator.

The repository tracks those gaps as files. APIs and behaviors that do not work yet are under issues/things-that-do-not-work/, and fixed ones move to issues/things-that-now-work/. One Hacker News commenter measured those directories at 58M and 74M, and counted 311 MiB of Rust code in test directories against 357 MiB outside them. The README says per-service fidelity scores are published with each release on the releases page. The sources do not reproduce any of those scores, so they cannot support a claim about how closely a given service matches AWS.

The guest post also includes a caution, though it is about Alf rather than the emulator. Simulation-based testing removed most of Alf's concurrency bugs, but testing on real servers then turned up different problems, 'because the real world exposes things a simulation cannot.'

One commenter reported a specific gap. As of v1.0.322, aws-emulator does not expose CORS headers, which stopped the local-surf browser extension from contacting it on localhost. The same commenter noted that the AWS Console uses its own proxy endpoint, which is not built entirely on the public AWS API endpoints. On this evidence, driving the AWS Console against the emulator is not a working path.

## Four ways to run AWS Emulator

- Server mode on Linux: install the RPM or Debian package and run aws-emulator. The AWS CLI or any SDK then points at it through environment variables.
- Windows and macOS: run the emulator in a container built from a short Dockerfile. Building from source is supported only on Linux, x86_64 and aarch64.
- Embedded mode for Rust tests: add the emulator as a dev-dependency and run one isolated instance per test, in-process. The test wires the emulator's HTTP client straight into the SDK client, so there is no endpoint URL, certificate, or environment variable to set.
- With an AI coding agent: install the aws-emulator skill with aws agent-toolkit add-skill, then ask the agent to set up the emulator. This needs AWS CLI version 2.35.0 or later.

A build from source serves HTTPS on 127.0.0.1:9297 with a self-signed certificate. The README links to a guide titled Pointing your AWS SDK at AWS Emulator, but it does not say how SDKs should handle that certificate. The build and run commands from the README are:

```bash
cargo build -p aws-emulator-router
cargo run -p aws-emulator-router
```

## Embedded mode in CI needs 100 GB of disk

The README says most users who are not modifying the emulator or using embedded mode install a prebuilt package. Embedded mode compiles the emulator into your test binary, so your project's first cargo test builds every service crate alongside your own code. That puts it on the same order of cost as a source build. The README asks for at least 100 GB of free disk for target/, a Rust toolchain, a C compiler, and a multi-core machine, and it says the build grows as services are added.

The README recommends three mitigations. Reuse one CARGO_TARGET_DIR across projects, cache target/ or use sccache in CI, and pin the emulator to a release commit so it is not rebuilt on every change. It says rebuilding after a change to one service is much faster than the cold build, but gives no timing figures for either.

Telemetry is on by default. The README says its records never include the contents of requests or responses, your code, credentials, or personal data, and that telemetry is not shared with third parties. There are four ways to turn it off:
- pass --telemetry off
- set EMULATOR_TELEMETRY=off
- add enabled = false under [telemetry] in config.toml, at ~/.aws/emulator/config.toml on Linux and macOS or %USERPROFILE%\.aws\emulator\config.toml on Windows, or at a path set by EMULATOR_CONFIG
- pass Telemetry::Off in the embedded options

EMULATOR_TELEMETRY also treats any value it does not recognize as off, with a warning at startup. Anyone building a tool that bundles the emulator is asked to tell users about telemetry and give them a way to turn it off.

## Will AWS maintain the emulator long term?

Commenters on Hacker News questioned whether the project is an experiment or a maintained product. One pointed to roughly 30,000 commits in three weeks. Others replied that it has official documentation at docs.aws.amazon.com/emulator. The sources state no support period, release cadence, or service-level commitment. The repository does not accept pull requests. AWS asks for bug reports that name the service, the operation, the SDK and its version, the request sent, and how the response differed from real AWS.

## No sourced comparison with LocalStack exists

Neither AWS source mentions LocalStack, so the sources offer no comparison of coverage, fidelity, or licensing. The comparisons available come from Hacker News commenters:
- One recommended Floci with Testcontainers and noted that Floci also works for GCP and Azure.
- A reply described Floci as breaking randomly between releases but 'still better than Localstack'. The same commenter said they would trust the new emulator at least as much as Floci and found the embedded Rust mode interesting.
- Another commenter said the new emulator 'sounds like it can be a much better alternative to Localstack/Floci and friends'.
- Others mentioned Ministack, described as a vibe-coded LocalStack replacement, and fakecloud, which is licensed AGPLv3, compared with this project's CC0.

For testing agent-written infrastructure code, the verifiable differences are structural. AWS publishes the emulator, its behavior is defined by tests corrected against real AWS, and it offers an in-process Rust mode with one isolated instance per test. A team choosing between it and LocalStack still needs to run its own test suite against both and read the per-release fidelity scores, because the sources contain no benchmark that settles the question.

## Questions this raises

### How closely does AWS Emulator match real AWS behavior?

The README says per-service fidelity scores are published with each release, but the launch sources do not quote any of them. Fidelity is defined by end-to-end tests that first pass against real AWS, and remaining gaps are tracked under issues/things-that-do-not-work/.

### What does it cost to run AWS Emulator in CI?

Prebuilt packages avoid the build cost, but embedded mode compiles every service crate into your test binary and needs at least 100 GB of free disk. The README recommends sharing CARGO_TARGET_DIR, caching target/ or using sccache, and pinning a release commit.

### How do I turn off telemetry in AWS Emulator?

Telemetry is on by default. You can pass --telemetry off, set EMULATOR_TELEMETRY=off, set enabled = false under [telemetry] in config.toml, or pass Telemetry::Off in the embedded options.

## Key facts

- AWS released AWS Emulator on November 11, 2026, with no AWS account required and no additional service fee.
- Agents built it from more than 400 Smithy API models covering more than 200 AWS services.
- Embedded mode for Rust tests needs at least 100 GB of free disk for target/, plus a Rust toolchain and a C compiler.
- Licensed under CC0 1.0, except code in vendor/, which is under Apache License 2.0; the repo showed 29,684 commits and 1.9k stars at launch.
- As of v1.0.322, the emulator does not expose CORS headers, according to one commenter.

## Sources

1. [AWS emulator](https://github.com/aws/aws-emulator) - github.com
2. [AWS Emulator and the engineer's job when agents write the code](https://www.allthingsdistributed.com/2026/11/aws-emulator-and-the-engineers-job-when-agents-write-the-code.html) - allthingsdistributed.com

Discussion read (practitioners' reactions, not a source): https://news.ycombinator.com/item?id=50456631