Index / tool

AWS Emulator

Category: Developer Tools
Rank: No. 889Tools index
Pricing: Free
Type: TOOL
Use case: Software Testing & Quality
Interfaces: API
GitHub: 5.8k stars
Latest release: v1.0.322
Date: Published Nov 11, 2026

About

AWS Emulator is a local program that serves an AWS API endpoint so you can test software without calling AWS or having an account. It runs as a server for the CLI and any SDK, or embedded in Rust tests with one isolated instance per test. It is meant for building and testing, not for production workloads or security testing. Fidelity scores for each service are published with every release.

What it does

A stand-in for the AWS APIs that runs on your machine, a development server or a CI runner. Calls that would reach AWS land on it instead and act on in-memory resources. There are two ways in: a standalone HTTPS server that the AWS CLI or any SDK is pointed at through environment variables, or an in-process mode for Rust tests, where the emulator's HTTP client plugs straight into the SDK client with no socket, certificate or endpoint URL. Each AWS service is its own crate, generated from that service's Smithy model, the machine-readable description of its wire protocol.

Why it's ranked here

Breadth and provenance. The workspace manifest lists one crate per AWS service, running alphabetically from Access Analyzer through Athena, Bedrock, DynamoDB and EC2 and well past them, all mounted behind a single endpoint. It lives in the aws GitHub organisation, the code is released under CC0 with only the vendored framework crates under Apache 2.0, and per-service fidelity scores ship with every release, so you can see how close a given service is before relying on it. Known gaps are tracked as files in the repository, split into what does not work yet and what has since been fixed.

What's good

Embedded mode gives real per-test isolation for Rust users: every instance owns a fresh in-memory engine, clients built from one instance share state, and two instances never do. Behaviour several services need is written once, including a single evaluation of IAM policy documents and a single reading of IAM trust policies, so two services asked the same authorization question cannot disagree. The server boots on a dedicated thread with a 64 MB stack and 16 MB worker stacks, and a crash on that thread exits non-zero rather than passing for a clean shutdown.

Tradeoffs

Telemetry is on by default in both modes and reports to an AWS endpoint. It can be switched off by flag, environment variable, config file or embedded option, and in embedded mode an off setting from any instance applies to the whole process. Building from source, which embedded mode requires, needs at least 100 GB of free disk and a multi-core machine, and is supported only on Linux; Windows and macOS users run the server in Docker. The repository does not accept pull requests, and the README rules out production workloads and security testing.

How to use it well

Best fit: integration tests and CI pipelines that talk to AWS through the CLI or an SDK and should run without an account or cloud charges. Rust teams get the most from embedded mode, but should follow the README's advice to share one build target directory, cache build output in CI and pin to a release commit, because the first build compiles every service. Check the published fidelity score for each service you depend on before trusting it. It does not stand in for real AWS when testing security or production behaviour, and teams outside Rust use the server mode.

Technical notes+

core/router/src/main.rs avoids #[tokio::main] on purpose: it spawns an emulator-main thread with EMULATOR_STACK_SIZE of 64 MiB (overridable via EMULATOR_STACK_BYTES, with a 32 MiB advisory floor that warns but is not clamped), builds the tokio runtime by hand with 16 MiB WORKER_STACK_SIZE, falls back to the main thread if the sized spawn fails, and exits 1 on a panic in that thread. It serves self-signed HTTPS on 127.0.0.1:9297 plus GET /__admin/health. core/router/src/lib.rs is generated and re-rendered on every service add; build_router chains forty #[inline(never)] mount_chunk_NN helpers that each register a handful of EmulatedService instances on a MultiServiceRouter sharing one InMemoryEngine, so no single frame holds the whole workspace. core/embedded/src/lib.rs exposes AwsEmulatorEmbedded::new, http_client (a SharedHttpClient), http_connector, credentials and certificate_authority; Telemetry::Off is process-wide and deletes the stored installation id and outbox. services/common/src/lib.rs holds claims_request and claims_modeled_route, which stop services sharing a SigV4 signing name (aws-marketplace, iam, sagemaker) from all claiming a request and producing 500 AmbiguousService, plus iam_authorization, iam_trust_policy and shared cross-service stores. The Athena crate's lib.rs is a thin shell: a smithy_model! macro over the JSON model plus an include of a build-generated service declaration.

Observed

License: CC0-1.0, with vendored framework crates under Apache-2.0
Language: Rust, as a Cargo workspace with one crate per AWS service
Interfaces: Standalone HTTPS server for the AWS CLI and SDKs; in-process HTTP client for Rust SDK tests
Install surface: RPM and Debian packages on Linux, Docker on Windows and macOS, or a Cargo build from source
Source build platforms: Linux x86_64 and aarch64 only
Source build disk: At least 100 GB free for the build output directory
Telemetry: On by default; off via command-line flag, environment variable, config file or embedded option
Contribution policy: Pull requests not accepted; bugs and fidelity gaps go to GitHub Issues
Unsafe code: Every crate source file read declares forbid(unsafe_code)

Read from README.md, Cargo.toml, core/router/src/main.rs, core/router/src/lib.rs, core/embedded/src/lib.rs, services/common/src/lib.rs, services/service-com-amazonaws-athena-amazonathena/src/lib.rs.

Tech Stack

Rust

Comments (0)

No comments yet

Editorially curated, with community endorsements as a secondary signal. Corrections welcome.