Test Your AWS Code Without the AWS Bill

You've written the tests. They pass locally. Then someone points out that half of them are hitting real AWS endpoints, which means real credentials, real latency, and occasionally real charges for resources nobody remembers creating. AWS Emulator is a local program that serves AWS API endpoints on your own machine, so your tests talk to emulated resources instead of the real thing. No AWS account required.

What It Does

AWS Emulator runs locally and serves as an endpoint for AWS APIs. Once it's running, you point the AWS CLI or any AWS SDK at it by setting environment variables, then run your code as usual. Your requests go to the emulator, not to AWS, so you're working with emulated resources throughout. It has no graphical interface—it's a headless program that just answers API calls—which makes it fit naturally into a development server or a CI pipeline.

There are two modes worth knowing about. In server mode, you install the emulator (an RPM or Debian package on Linux, or a container built from a short Dockerfile on Windows and macOS) and point your SDK at its endpoint. In embedded mode, which is for Rust tests, you add the emulator as a dev-dependency and run it in-process, with one isolated instance per test. Embedded mode skips the endpoint URL, certificate, and environment variables entirely—your test wires the emulator's HTTP client straight into the SDK client.

Why It's Cool

• It removes the AWS account from the equation. For anyone writing integration tests against AWS services, the usual setup involves accounts, credentials, and cleanup logic. Skipping all of that makes tests faster to write and easier to run anywhere.

• The embedded mode is a genuinely nice design. Running one isolated emulator instance per test, with the HTTP client passed directly into the SDK, means no port juggling, no shared state between tests, and no environment configuration. That's the kind of ergonomics you usually have to build yourself.

• There's an AI agent path. If you use a coding agent, there's a published skill you can install with a single aws agent-toolkit add-skill command (AWS CLI 2.35.0 or later required), and the agent handles setup. It's a small thing, but it acknowledges how people actually bootstrap projects now.

• Honesty about fidelity. Rather than claiming perfect AWS compatibility, the project publishes fidelity scores with each release and tracks gaps in an issues/ directory—things that don't work yet live in issues/things-that-do-not-work/, and fixed items move to issues/things-that-now-work/. That's a refreshingly transparent way to handle the inevitable "does this support X?" question.

• The cost model is simple. There's no additional service fee for the emulator. You only pay for AWS resources when you actually deploy to AWS.

One caveat the README is explicit about: this is for building and testing, not production workloads, and not for testing security.

How to Try It

The fastest route depends on your setup.

With an AI coding agent, install the skill and ask your agent to set up the emulator:

aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1

Server mode on Linux: install the RPM or Debian package and run aws-emulator. Then set environment variables to point your SDK at the endpoint.

Server mode on Windows or macOS: run the emulator in a container built from a short Dockerfile.

Embedded mode (Rust): add the emulator as a dev-dependency and run it in-process. Be aware that this compiles the emulator into your test binary, so the build-from-source prerequisites apply—that means a Rust toolchain, a C compiler, a multi-core machine, and at least 100 GB of free disk for target/, since the workspace has one crate per AWS service.

Before committing, check the fidelity scores on the releases page and the guide on checking whether your project works with AWS Emulator. Full setup instructions live in the AWS Emulator User Guide, and the code is at github.com/aws/aws-emulator.

Final Thoughts

AWS Emulator is best suited to teams that write integration tests against AWS services and want them to run offline, in CI, or without credential management—and to Rust developers who want per-test isolation without the ceremony. The fidelity scoring is the thing to watch: if your project depends on a service or behavior that isn't covered yet, you'll want to check before you restructure your test suite around it. But as a way to stop your tests from calling AWS, it's a practical, well-documented answer to a problem most of us have just lived with.

Follow @githubprojects for more developer tools and open source projects.