AWS Releases Its Own Local Emulator for Testing AWS APIs

For years, developers who wanted to test cloud code without touching a real account had to rely on third-party tools. Now AWS has published its own answer: the aws/aws-emulator repository, a local emulator that serves an AWS-compatible API endpoint on your machine, a development server or a CI runner.

What the emulator does

The idea is simple. You start a local process, point the AWS CLI or an SDK at its endpoint using environment variables, and run your code as usual. Requests never reach AWS, so no account, credentials or cloud bill are involved. The project states there is no service fee for the emulator itself; you pay only for real AWS resources when you deploy.

It has no graphical interface and is explicitly meant for building and testing. AWS warns against using it for production workloads or for security testing, since an emulator cannot reproduce the guarantees of the real services.

There are two ways to run it:

• Server mode: install an RPM or Debian package on Linux, or run it in a container on Windows and macOS. Any SDK or the CLI can talk to it over HTTPS on a local port, using a self-signed certificate.
• Embedded mode: add the emulator as a dev-dependency and run it inside your test process, one isolated instance per test. There is no endpoint URL, certificate or environment variable to configure, because the test hands the emulator's HTTP client directly to the SDK client.

AWS also ships an agent skill so an AI coding agent can set the emulator up for you, which requires a recent AWS CLI release.

How it is built

The codebase is a Rust workspace with one crate per AWS service. Each service crate is driven by its Smithy model, the same interface description language AWS uses to define its APIs, which generates the wire-protocol layer. Operations live in separate files, and each service keeps its own in-memory state. A router binary mounts every service behind one endpoint.

That architecture has a cost. Building from source is supported on Linux only, and the project recommends at least 100 GB of free disk for the build directory, since a debug build compiles every service crate. Embedded mode inherits this: your first test run compiles the emulator alongside your own code. The maintainers suggest sharing one target directory across projects, caching build output in CI and pinning to a release commit.

Fidelity and openness

The most interesting part for practitioners is how AWS frames accuracy. Each release publishes fidelity scores per service, and known gaps are tracked as files in the repository, split between behaviors that do not work yet and ones that have been fixed. That is a candid admission that emulation is never complete, and it gives teams a way to check whether their own stack is likely to work before adopting it.

The licensing is notable too. The main code is under CC0, effectively public domain, while vendored framework crates remain under Apache 2.0. However, the repository does not accept pull requests. Bug and fidelity reports go through GitHub Issues, so this is source-available in spirit but not a community-governed project.

Telemetry is on by default

Builders should note that the emulator reports usage data to AWS unless told otherwise. AWS says the data is minimized and excludes request and response contents, code, credentials and personal data, and that it is not shared with third parties. It can be disabled with a command-line flag, an environment variable, a config file entry or an option in the embedded API. Anyone shipping a tool that bundles the emulator is asked to tell their users and offer an opt-out.

Why it matters

Local AWS emulation has been dominated by community projects such as LocalStack and Moto, which have filled the gap with varying coverage. An official emulator with published fidelity scores changes the conversation: teams get a vendor-backed option, and the third-party tools face a direct competitor that tracks AWS's own API definitions.

What to watch next is breadth and speed. How many services reach high fidelity, how quickly reported gaps close, and whether the heavy build requirements shrink will decide whether this becomes the default test target or stays a useful complement to existing tools.