AWS Emulator runs AWS APIs on your laptop for free, and AI agents wrote every line of it

AWS released AWS Emulator on November 11, a free local emulator of AWS APIs for tests and CI that needs no AWS account. AWS says autonomous agents wrote and fixed all of its code with no human review. It skips IAM policy checks, keeps everything in memory and sends telemetry by default. Check the fidelity scores before you drop your current setup.

If your team pays for AWS resources just to run integration tests, try AWS Emulator on one test suite this week. AWS released it on November 11 as a local program that answers AWS API calls on your own machine or in CI, with no AWS account and no service fee. AWS also says no person on its team wrote or reviewed any of its code.

What changed

AWS Emulator serves an AWS API endpoint locally. You point the AWS CLI or an AWS SDK at it with environment variables, and your code runs unchanged against emulated S3 buckets, DynamoDB tables, SQS queues and other resources. According to the AWS Emulator User Guide, it returns the same validation errors AWS does and keeps the resources you create until it stops.

How you run it:

• Linux: an RPM or Debian package for x86_64 or aarch64, run as a command-line tool.
• macOS and Windows: a Docker container built from a Dockerfile AWS supplies.
• Rust tests: an embedded mode that runs one isolated emulator inside each test process.
• AI coding agents: an aws-emulator skill that installs and starts the emulator and checks whether your project’s AWS calls are covered. It needs AWS CLI 2.35.0 or later.

The code is on GitHub under the CC0 public-domain dedication, except vendored framework code under Apache 2.0. The repository takes bug reports but not pull requests.

Agents built it, and AWS published their bug list

In an About Amazon post, AWS senior principal engineer Matthew Goldberg says the project started as a weekend experiment with Kiro, AWS’s coding agent. It now runs three teams of agents. One writes test scenarios from AWS’s public API models and checks each against real AWS. One replays those tests against the emulator and files issues for failures. One fixes each issue, and a gate of compile checks plus reviewing agents for coding standards, security and regressions decides what merges.

Goldberg says the suite holds tens of thousands of these fidelity tests, that hundreds of agents work on the code at once and that thousands of issues get fixed a day. The repository keeps every issue: fixed ones under issues/things-that-now-work and open ones under issues/things-that-do-not-work. AWS says the emulator updates many times a day.

What it does not do

The user guide lists the limits plainly:

• No IAM. It does not evaluate IAM or resource-based policies the way AWS does. AWS says not to use it to test security.
• One Region, one account. It accepts any Region and account ID but does not keep resources separate. Run one emulator per Region, each on its own port.
• Checked in one Region. AWS verifies behavior in US West (Oregon), and US East (N. Virginia) for global services.
• In memory only. Everything is deleted when it stops, and AWS has not tested it for long-running or load testing.
• Telemetry on by default. AWS says it sends anonymous usage and error data, never request contents, code or credentials. Turn it off with --telemetry off or EMULATOR_TELEMETRY=off.
• Big source builds. Building from source, which embedded mode requires, needs at least 100 GB of free disk for Rust build output.

Fidelity scores decide whether it replaces your current emulator

Plenty of teams already test against a third-party emulator such as LocalStack or a set of mocks. A free first-party option changes the default question from “what does it cost” to “does it match AWS for the calls we make.” AWS publishes a fidelity score per service with each release on the releases page, and the test manifest sits in a separate evaluation suite repository.

Here is the order to work in:

• List the AWS operations your tests call, then check them against the fidelity scores and the manifest. The skill can do this for you.
• Run one CI job against both your current setup and AWS Emulator for a week and compare failures.
• Keep a real AWS test stage for anything that depends on IAM, multiple Regions or accounts, or load.
• Pin a release in CI. An emulator that changes many times a day can change a test result between runs.

The bigger story is how it was built. AWS is betting its name on code no engineer reviewed, and the guardrail it credits is a test suite checked against the real service. That is a model worth copying for any team handing work to agents. For how Apple is limiting what agents can reach on a Mac, see Full Disk Access for AI agents in macOS 27.3.