AWS Emulator is a free local copy of the AWS APIs that runs on your laptop or in your CI pipeline, and Amazon says no human wrote or reviewed a single line of it. Hundreds of AI agents built it, checking every behaviour against the real AWS cloud. It is useful today for building and testing without an AWS account. Its own scorecard also shows the limits: at launch, 56.5% of its 42,937 fidelity tests pass, and it does not check IAM policies the way AWS does.
That combination makes AWS Emulator interesting twice. For developers it is a new, free option for local AWS testing, arriving months after LocalStack put its free edition behind an account. For anyone building with AI agents it is a rare public look at what an agent factory produces when the guardrails, not the model, carry the weight.
What AWS Emulator is
AWS Emulator answers AWS API calls on your own machine. You point the AWS CLI, an AWS SDK or a coding agent at a local HTTPS endpoint on port 9297, and your code creates queues, tables and buckets that live only in memory. AWS released it on 11 November 2026, with the source code on GitHub.
- Coverage. AWS built it from 438 AWS API models covering more than 200 services. The scorecard of the first release contains test results for 355 services.
- Installation. RPM and Debian packages for Linux, a container for macOS and Windows, and an embedded mode that compiles the emulator into Rust test binaries. Coding agents can install an
aws-emulatorskill with AWS CLI 2.35.0 or later. - Price and licence. There is no service fee. The code is dedicated to the public domain under CC0, with vendored code under Apache 2.0. The repository does not accept pull requests, only bug and fidelity reports.
- Telemetry. Usage data goes to AWS by default. You switch it off with
--telemetry off, theEMULATOR_TELEMETRY=offvariable or a line inconfig.toml. According to the README, request contents, code and credentials are never collected.
The emulator is written in Rust, with one crate per AWS service. Building it from source needs at least 100 GB of free disk, so most teams will use the prebuilt packages.
How AI agents built AWS Emulator without human review
The project started as a weekend experiment by Matthew Goldberg, a senior principal engineer at AWS. He was inspired by Anthropic’s experiment in which agents built a C compiler. His takeaway was that agents can build a faithful copy when they have a precise specification and a reference to check against. AWS has both: the public AWS API models are the specification, and the real AWS cloud is the reference.
Goldberg gave Amazon’s coding agent Kiro a three-step prompt: write tests based on the AWS CLI, run them until they pass against real AWS, then build an in-memory version that passes the same tests. A rough copy of Amazon SQS took about 15 minutes. By Monday his team was using the weekend prototype for testing. Turning that into a product took much longer and, in his words, needed guardrails to keep the agents on track.
The production system splits the work into three bounded teams, because agents do better on narrow tasks.
- Test writers turn the API models into realistic scenarios, such as creating a queue, sending, receiving and deleting a message, and verify every test against real AWS before it is accepted. The suite runs to tens of thousands of tests.
- Issue finders replay those tests against the emulator and file each difference in a backlog, grouping failures that probably share a root cause. The repository started as an empty web server that accepted requests for all 438 API models and did nothing.
- Fixers each take one issue, find the root cause and change the code. A change only merges after four checks: it must build, meet the coding standards, pass a security review and cause no fidelity regressions.
Hundreds of agents work at the same time and, according to AWS, fix thousands of issues a day. The public history counted 29,684 commits on the main branch at launch. The agents did not always choose sensibly. An early version built its own Python interpreter to run AWS Lambda functions, until the agents were steered towards existing libraries. Goldberg’s metaphor for the guardrails is a colouring book: like a young child learning to draw, agents need clearly outlined areas to produce a coherent picture. This is harness engineering at industrial scale. The model is interchangeable, and the tests, the merge gate and the release pipeline decide what ships.
What the fidelity scores show
Each release publishes a scorecard. We downloaded scores.json.gz from release v1.0.322, scored on 11 November 2026, and counted the results ourselves. A test only passes if the emulator returns exactly what AWS returned: status code, response body, error code and message, and the resulting state.
- 42,937 test units in total, of which 24,243 pass, or 56.5%. 18,614 fail and 80 were skipped.
- Of the 68,007 individual steps in those tests, 73.2% pass. Many scenarios fail on one step out of several.
- Among the 342 services with at least ten tests, the median pass rate is 61.3%. Forty services score 90% or more, and 124 score below 50%.
| Service | Tests | Pass rate |
|---|---|---|
| EventBridge | 967 | 71.5% |
| KMS | 505 | 71.3% |
| Step Functions | 982 | 70.0% |
| SNS | 635 | 69.3% |
| DynamoDB | 1,694 | 68.1% |
| SQS | 1,523 | 67.8% |
| S3 | 2,814 | 62.7% |
| Lambda | 3,006 | 51.9% |
| EC2 | 2,470 | 38.8% |
| CloudFormation | 4,206 | 18.9% |
Read these numbers with two caveats. AWS warns that adding tests can lower a score while the emulator improves, because the new tests often probe edge cases. And a failing test often means one wrong error message, not a broken service. Still, the scorecard rules out the idea of a complete AWS on your laptop. The honest description is a fast, free emulator that gets the common paths of the popular services mostly right, with a public list of what it gets wrong in the issues/things-that-do-not-work folder.
Where you should not trust it
AWS is clear about the limits, and they matter more than the averages. The security documentation lists them.
- Permissions. The emulator does not evaluate IAM policies, permission boundaries, S3 bucket policies or KMS key policies the way AWS does. A request that AWS would deny can succeed locally, and the reverse. Never use it to test access control.
- One account, one Region. Calls across accounts or Regions are not supported, and all state lives in memory until the emulator stops.
- Code is not isolated. Function code you hand to the emulator runs with your own user’s permissions on your machine.
- Unverified behaviour. Operations without a passing test are not verified. Unimplemented operations return an HTTP 501 error, which is better than a fake success.
- Not for production or security testing. Throttling, outages and load are out of scope. Final validation still happens on real AWS.
One practical risk deserves a line in every test script. If AWS_ENDPOINT_URL is not set, your SDK quietly calls real AWS with whatever credentials it finds. AWS advises unsetting real credentials before you run tests.
Why it arrives at the right time for LocalStack users
LocalStack has long been the default tool for local AWS testing. In March 2026 it merged its community and Pro editions. The free localstack/localstack image stopped receiving updates and security patches, and the current version needs an auth token tied to an account, with the free tier aimed at non-commercial use. Older pinned versions still run, but without fixes. Since then teams have been trying open alternatives such as Floci and Moto.
AWS Emulator enters that gap with an unusual offer: an emulator from the vendor itself, verified against the real service, in the public domain. It is not yet a drop-in replacement: AWS Emulator keeps no state between runs, supports one account and one Region, and skips IAM policy evaluation. On Hacker News developers asked whether it is an experiment or a product. An AWS employee answered that AWS plans to maintain it, and others replied that a forum comment is not a support commitment. The CC0 licence softens that risk: if AWS ever stops, anyone may fork the code and the tests.
What it means for European development teams
For organisations that keep test data and credentials on a short leash, a local emulator has real advantages. Test runs need no AWS account, no cloud resources to clean up and no access keys in the CI system, and test data never leaves your machine. The telemetry default is the one point to change on day one.
- Start in CI, not in production thinking. Run your integration tests against AWS Emulator in the pipeline, and keep a smaller test stage on a real AWS account before release.
- Treat HTTP 501 as a failure. Configure your tests so an unimplemented operation stops the run instead of being skipped.
- Check your services on the scorecard. Look up the pass rate and the open issues of the services you use before you rely on them. For CloudFormation and EC2 heavy stacks, expect gaps.
- Keep IAM tests on AWS. Policies, bucket policies and KMS key policies are tested only in the cloud.
- Switch off telemetry in pipelines with
EMULATOR_TELEMETRY=off, and document that choice for your data protection officer. - Set the endpoint and unset real credentials in the same script that runs the tests, so a misconfigured job cannot reach production.
The build method is worth studying too. Teams that already let agents write code, as in a simulation-based test setup, will recognise the pattern: a reference to check against, tests that are verified before they count, and a gate that no change bypasses. The AI harness around the model is what turns a weekend prototype into something you can ship.
The tests are the real product
The code of AWS Emulator was written by agents and will be rewritten by agents a thousand times a day. What humans built, and what makes the project credible, is the evaluation suite: tens of thousands of scenarios, each verified against at least two sandboxed AWS accounts and published under CC0. Anyone can run it against AWS Emulator, and in principle the same scenarios could become a yardstick for any AWS emulator. For organisations planning their own agent projects, that is the lesson to copy. Before you ask which model to use, ask what your real AWS is: the reference your agents can check every change against.
Frequently asked questions about AWS Emulator
Is AWS Emulator free?
Yes. AWS charges no fee for the emulator, and the code is in the public domain under CC0. You only pay for resources you deploy on real AWS.
Did humans review the code of AWS Emulator?
No. According to AWS, the team neither wrote nor reviewed the code. Humans designed the specifications, the test machinery, the merge gate with build, review, security and fidelity checks, and the release pipeline.
Can AWS Emulator replace LocalStack?
For many local and CI tests of common services, it can be a free alternative. It lacks persistence, multi-account and multi-Region support and IAM policy evaluation, so check the scores of the services you use before switching.
Can I test IAM permissions with AWS Emulator?
No. The emulator does not evaluate IAM, bucket or KMS key policies the way AWS does, so a request AWS would deny may succeed locally. Test permissions and other security controls on real AWS.
Which systems does AWS Emulator run on?
Linux through RPM or Debian packages, macOS and Windows through a container, and Rust projects through an embedded mode. It listens on 127.0.0.1:9297 with a self-signed certificate.
