Glonce

AWS Emulator runs AWS APIs locally for testing, no account needed

toolsThe Glonce editorsHacker News🔥80Glonce rating80Impact65Novelty60Relevance95Surprise55Players85Credibility85
AWS Emulator runs AWS APIs locally for testing, no account needed

The aws/aws-emulator repository presents AWS Emulator, a local emulator of the AWS APIs. You use it to test software without calling AWS, on your own machine, on a development server or in continuous integration. No AWS account is needed: requests go to the emulator, not to AWS, so you work with emulated resources. The README says the emulator has no additional service fee; you pay only for AWS resources when you deploy on AWS.

The emulator is a local program that serves an AWS API endpoint and has no graphical interface. After you start it, you set environment variables to point the AWS CLI or an AWS SDK at its endpoint, then run your code as usual. Run from source, it serves HTTPS on 127.0.0.1:9297 with a self-signed certificate. There is also an embedded mode: you add the emulator as a dev-dependency and run it in-process, one isolated instance per test. That mode needs no endpoint URL, certificate or environment variable; the test passes the emulator's HTTP client straight to the SDK client.

There are several ways to install it. On Linux you install an RPM or Debian package and run aws-emulator. On Windows and macOS you run it in a container built from a short Dockerfile. You can also install an aws-emulator skill with the command aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1 and ask a coding agent to set the emulator up; that route needs AWS CLI version 2.35.0 or later.

The README is explicit about scope: AWS Emulator is for building and testing, and should not be used for production workloads or to test security.

Coverage varies by service. Fidelity scores showing how closely each service matches AWS are published with each release on the releases page. Individual gaps are tracked in the repository's issues/ directory: APIs and behaviors that do not work yet sit under issues/things-that-do-not-work/, and fixed ones move to issues/things-that-now-work/. The README also points to a page for checking whether your own project is expected to work with the emulator.

Building from source is supported on Linux (x86_64 and aarch64) and is needed if you modify the emulator, run it from a checkout or use embedded mode. Prerequisites are a Rust toolchain with Cargo, a C compiler such as GCC or clang, a multi-core machine, and at least 100 GB of free disk for target/. The workspace has one crate per AWS service, so a debug build of everything is large and grows as services are added. A cold full build compiles every service crate and takes a while; rebuilding after a change to one service is much faster. The build commands are cargo build -p aws-emulator-router and cargo run -p aws-emulator-router.

Embedded mode compiles the emulator into the test binary, so a project's first cargo test builds the emulator's service crates alongside its own code. The README says to budget a first build and target/ on the same order as building from source, then expect fast incremental builds. Its recommendations: 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.

Telemetry is on by default. The README says the emulator is configured to collect and report usage data to AWS to gain insight into how it is used, with strict data minimization that prevents identification of specific users, accounts or organizations. Records never include the content of requests or responses, code, credentials or personal data, and telemetry is not shared with third parties. Details are deferred to a separate page, Telemetry in AWS Emulator. To turn it off you can start the emulator with --telemetry off (short form -t), which applies to that process only; add --telemetry off after the image name in a docker run command; set EMULATOR_TELEMETRY to off, which applies to every emulator started from that shell; or set enabled = false under [telemetry] in config.toml (~/.aws/emulator/config.toml on Linux and macOS, %USERPROFILE%.aws\emulator\config.toml on Windows, or a path given in EMULATOR_CONFIG). In embedded mode you pass Telemetry::Off in the options when creating the emulator. EMULATOR_TELEMETRY accepts on, true or 1 to turn telemetry on and off, false or 0 to turn it off, case-insensitively; any other value turns it off and the startup notice shows a warning. Builders of tools that include the emulator, such as test frameworks, are asked to tell their users about telemetry and give them a way to turn it off; they can also ship with telemetry off.

The repository does not take pull requests. Bugs and fidelity gaps go to GitHub Issues, and the README says the most useful report names the service, the operation, the SDK and version, the request sent, and how the response differed from real AWS. The software is licensed CC0 1.0 Universal, except the code in vendor/, which is under the Apache License 2.0.

Key facts

  • AWS Emulator is a local program that serves an AWS API endpoint so software can be tested without calling AWS and without an AWS account, on a laptop, a dev server or in CI.
  • An embedded mode runs one isolated emulator instance per test in-process, but it compiles the emulator into the test binary; the README advises budgeting a first build and target/ comparable to a source build, which needs at least 100 GB of free disk.
  • Telemetry reporting usage data to AWS is on by default; it can be turned off with --telemetry off, the EMULATOR_TELEMETRY variable, config.toml or an embedded-mode option.
  • Install paths: an RPM or Debian package on Linux, a Dockerfile-based container on Windows and macOS, or an agent skill that needs AWS CLI 2.35.0 or later.
  • The README says it is for building and testing only, not production workloads or security testing; the code is CC0 1.0 Universal (vendor/ is Apache 2.0) and the repo takes no pull requests.

Why it matters

Testing cloud code usually means either calling real AWS or relying on a third-party imitation. This repository is a first-party emulator of the AWS APIs that runs locally, in CI or in-process, with no account and no AWS charges. The emulator itself carries no service fee, and you pay only for AWS resources when you deploy on AWS. Embedded mode goes a step further by giving each test its own isolated emulator instance with no endpoint or certificate setup.

Who it affects

Developers who write code against AWS SDKs and want tests that do not touch an AWS account, and teams running those tests in CI. Rust developers are affected most directly, because embedded mode is added as a dev-dependency and built with cargo test. Authors of test frameworks or other tools that bundle the emulator are asked to disclose telemetry to their own users and offer a way to disable it. Anyone who needs production-like behavior or security testing is told this is not the tool.

How to use it

On Linux, install the RPM or Debian package and run aws-emulator. On Windows and macOS, run it in a container built from a short Dockerfile. Alternatively, install the aws-emulator skill with aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1 (AWS CLI 2.35.0 or later) and ask a coding agent to set it up. Then set environment variables so the AWS CLI or SDK points at the emulator's endpoint and run your code as usual. For embedded mode, add the emulator as a dev-dependency and wire its HTTP client into the SDK client. To limit build cost, reuse one CARGO_TARGET_DIR across projects, cache target/ or use sccache in CI, and pin the emulator to a release commit. To opt out of telemetry, use --telemetry off, set EMULATOR_TELEMETRY=off, or put enabled = false under [telemetry] in config.toml. The code is CC0 1.0 Universal, except vendor/ under Apache 2.0.

How solid is it

This is the project's own README in an official aws repository, so the descriptions of behavior, install paths and telemetry options are first-party statements. How faithfully each service matches AWS is not stated in the README itself: fidelity scores are published with each release on the releases page, and known gaps are tracked in the issues/ directory. No release date, version number or maturity status is given, and no list of supported services or comparison with other emulators is given.

Risks and caveats

The README says not to use the emulator for production workloads or to test security. Telemetry is on by default and reports usage data to AWS; the README says records exclude request and response content, code, credentials and personal data, and are not shared with third parties, but the full list of collected fields lives on a separate page. Any unrecognised value of EMULATOR_TELEMETRY turns telemetry off, with a startup warning. Source and embedded builds are heavy: at least 100 GB of free disk for target/, growing as services are added, and a slow cold build on fewer cores. Source builds are supported on Linux only (x86_64 and aarch64). Services and behaviors not yet working are listed under issues/things-that-do-not-work/, and the repository takes bug reports but not pull requests.

“AWS Emulator is for building and testing. Don’t use it for production workloads or to test security.”

— AWS Emulator README