AWS Emulator: what it is and how to run it locally
2026-11-12 · 4 min read
AWS Emulator is a free program from Amazon that imitates the AWS APIs on your own machine, so you can test an app against S3, DynamoDB, SQS and others without touching a real account. You install it, start it, set a few environment variables, and the normal AWS CLI talks to it at https://127.0.0.1:9297.
It launched on November 11. AWS executive @SwamiSivasubram announced it on X, saying it "gives coding agents a local copy of AWS to test against." His post links to a longer essay he wrote for Werner Vogels' blog, which says the emulator was built from more than 400 API models covering more than 200 AWS services.
Agents wrote all of it
No person wrote the code. In Amazon's announcement, senior principal engineer Matthew Goldberg says: "Our team hasn't written or reviewed any of the code."
According to Amazon, the work is split across three teams of agents. One writes tests from the public API definitions and checks them against real AWS. A second replays those tests against the emulator and files every failure as an issue. A third assigns one agent per issue, and each fix has to pass a merge gate that covers build, review, security and fidelity before it lands.
Developer Simon Willison, on his blog, called it "Finally, an official emulator from AWS" and counted 29,684 commits in the project's first three weeks. It is written in Rust and released under CC0, which puts it in the public domain.
How to try it
These steps come from the AWS News Blog walkthrough, which used Amazon Linux 2023.
Install and start it:
PKG=https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest
sudo dnf install -y $PKG/aws-emulator-x86_64.rpm
aws-emulator
In a second terminal, point the AWS CLI at it:
export AWS_ENDPOINT_URL=https://127.0.0.1:9297
export AWS_SHARED_CREDENTIALS_FILE=~/.aws/emulator/9297/emulator_credentials
export AWS_CONFIG_FILE=~/.aws/emulator/9297/config
export AWS_REGION=us-east-1
The blog lists a few more variables, and it tells you to unset any real AWS keys in that shell first. Then use AWS the way you always do:
aws s3 mb s3://local-getting-started
aws s3 cp hello.txt s3://local-getting-started/
aws s3 ls s3://local-getting-started/
On macOS and Windows there is no installer yet. You build a container from a short Dockerfile in the docs, and AWS does not publish a ready-made image. Willison flagged that as the thing he most wants fixed.
If you use a coding agent, the README gives a one-line setup: aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1. It needs AWS CLI 2.35.0 or later.
What it does and what it costs
| Question | Answer |
|---|---|
| Price | No service fee. You pay AWS only when you deploy for real. |
| License | CC0, with vendored code under Apache 2.0 |
| Where it runs | Linux packages (RPM and Debian), Docker on macOS and Windows |
| Data | Held in memory, gone when the emulator stops |
| Unsupported API calls | Return HTTP 501, Not Implemented |
| Telemetry | Anonymous usage data, on by default. Turn it off with --telemetry off |
Where it falls short
AWS is direct about the limits. The README says not to use it for production workloads or to test security. It does not evaluate IAM or resource policies the way real AWS does, it acts as a single account, and it has no cross-account or cross-region behavior. So a permissions bug will sail through local tests and still bite you in the cloud.
Fidelity also varies by service. AWS publishes pass counts per service with each release. One developer writing on DEV added up an early score file and found about 56.5% of test units passing. That is his count, not an AWS figure, and the project ships several releases a day, so check the current scores for the services you depend on.
Our read
We would use it today for one job: fast, free test runs on the common services. Coding agents run tests constantly, and every run against a real account costs time and money, so a local stand-in pays for itself quickly.
How Amazon built it interests us more than the tool does. Nobody reads the agents' code, so the tests carry all the weight: thousands of them, written against real AWS, and every change has to pass before it merges. Google DeepMind did something similar with AlphaProof Code, where machine-checked proofs stand in for a human reviewer. The Linux kernel went the other way and kept a person on the hook for every AI-assisted patch. Kiro, the AWS tool Amazon says produced the first prototype, is the subject of our Kiro Bots post.
A small business can borrow the same rule. Hand a task to an AI agent when the result can be checked automatically, like an invoice total that must match or a booking that must not overlap another. If you cannot write the check, keep a person in the loop.
That is what we look for in New Face Design's free process audit: which tasks in your office already have a clear check, and which ones still need one.