AWS Emulator puts Amazon's cloud on your laptop, and no human wrote the code

What it's about

Amazon Web Services (AWS), the world's largest cloud provider, released the AWS Emulator on November 11, 2026. It's a free program that mimics AWS cloud services on your own machine. Developers, and more and more often AI coding assistants, can use it to test their code against a kind of local copy of AWS instead of spinning up real, paid resources in the cloud. According to the AWS News Blog, the tool is generally available now at no extra charge. You only pay once you actually deploy to the cloud.

The real headline, though, is who built the emulator. Matthew Goldberg, Senior Principal Engineer at AWS, writes in a post on About Amazon:

“The emulator was written entirely by autonomous agents. Our team has not written or reviewed a single line of the code.”

The source code is public on GitHub under CC0. That's a dedication that puts the code in the public domain, so anyone can use it without conditions. According to Unite.AI, bundled third-party code under Apache 2.0 is the exception. The full commit history is public too.

How the emulator works

The emulator is written in Rust so it uses little compute and memory. It runs as a local web server and accepts HTTPS requests at 127.0.0.1:9297, so by default only your own machine can reach it. On Linux, you install it from RPM or Debian packages. On macOS and Windows, you have to build a Docker image yourself, meaning an isolated software container, from a short Dockerfile in the documentation, because AWS doesn't provide a ready-made image. You can also compile the program from source. Simon Willison hopes AWS will improve this. Ideally, he says, it would be a single binary that you can simply run alongside test environments in any language and on any platform.

You point the AWS command line interface (CLI), the SDKs and coding agents such as Amazon's Kiro or Anthropic's Claude Code at the emulator using environment variables like AWS_ENDPOINT_URL. Your actual application code doesn't need to change. A test that creates a DynamoDB table, writes an item and reads it back then runs entirely on your laptop, with no internet connection at all. For Rust projects there's also an embedded mode (the aws-emulator-embedded package) that starts the emulator directly inside the test process. Each instance keeps its own state, so tests can run in parallel. Resources live in memory and are deleted when the emulator shuts down.

There's a safety measure too: the emulator only accepts access keys that start with “EMULATOR”.

How close is it to the real cloud?

The foundation is AWS's public API models (in Smithy format). These are machine-readable descriptions of how each service is supposed to behave, and the official SDKs use the same models. That's why requests and error messages look just like they do on AWS. According to Goldberg, the project started as an empty web server that accepted requests for 438 API models. GeekWire reports more than 400 API models covering over 200 services. InfoWorld, on the other hand, says the emulator supports “all 426 AWS services.” So the figures don't match, and “supported” doesn't mean “fully replicated” anyway.

AWS measures how accurately a service is replicated with what it calls fidelity tests. These are short, scripted sequences like “create a queue, send a message, delete the queue” that were first checked against the real AWS cloud. The emulator only passes a test if it returns exactly the same response for every call, down to the status code, body and exact error text. According to Unite.AI, each test was verified against at least two separate AWS test accounts. With every release, AWS publishes a per-service score in the form “k of n” tests passed. AWS itself points out that the score can drop when new tests are added, even if the emulator has improved. Any behavior without a matching test is explicitly considered unverified.

Features that are still missing return an error instead of quietly reporting success. According to shiftdelete.net and Unite.AI, that's HTTP 501 (“Not Implemented”), while InfoWorld says HTTP 503. The agents keep a public list of known gaps in a GitHub folder called “things-that-do-not-work”.

Built by three agent teams

It all started as a weekend experiment, inspired by Anthropic's demonstration earlier this year in which a team of Claude agents built a C compiler. Goldberg gave the coding agent Kiro a three-part instruction: write tests, check them against real AWS, and build an in-memory implementation that passes those tests. After about 15 minutes, he had a usable replica of Amazon SQS, the queuing service. By Sunday evening, according to GeekWire, Kiro had built a rough version of the rest of AWS, with obvious gaps. By Monday, Goldberg's team was already using it for its own tests.

Today, three agent teams run the production version on Amazon Bedrock AgentCore, AWS's platform for running AI agents:

Every change has to pass a merge gate, an automated checkpoint before it's merged into the code. It checks whether everything compiles, whether coding standards are met and whether fidelity with AWS is preserved. On top of that, a dedicated security agent hunts for vulnerabilities, once during development and again in the release pipeline. “Without this gate, we wouldn't trust what our agents build,” Goldberg writes. Hundreds of agents work in parallel and, by his account, fix thousands of issues every day. Simon Willison counts 29,684 commits in the first three weeks. The repository doesn't accept outside pull requests, but you can report bugs through GitHub Issues.

Humans built the scaffolding: specifications, test infrastructure, merge gates and the release pipeline. Swami Sivasubramanian, AWS Vice President of Agentic AI, offers an example in a guest post on CTO Werner Vogels' blog. He had Kiro rebuild a replication engine for “Alf”, Amazon's early lock service. Building it by hand had taken about four months back then. With Kiro, it initially took four supervised nights, because the agent couldn't verify its own results. With a specification and a test environment, it was done in about two hours. His conclusion: engineers are becoming “system orchestrators” who define what's correct, while agents write the code.

Limitations at launch

• No real permission checks: The emulator doesn't evaluate IAM, AWS's permissions and access system, or resource-based policies the way AWS does. A request that AWS would reject may go through locally. AWS explicitly says you shouldn't use it to test whether an app is secure.
• One account, no regions: Each instance behaves like a single account (000000000000). There's no cross-account or cross-region behavior.
• No failure simulation: According to IDC analyst Devin Pratt (speaking to InfoWorld), the emulator doesn't simulate throttling, outages, snapshots or regional differences. Advait Patel, an SRE at Broadcom, warns that this is exactly what takes systems down in production. If you never see a 429 error or a timeout, you never test your retry logic either. There's a risk of false confidence if “passed locally” is treated as “ready to ship.”
• No sandbox: Executed code isn't isolated. If real production credentials are in a function you're testing locally, Pratt says it can still reach real AWS resources.
• Telemetry is on: By default, the emulator sends anonymous usage and error data until you turn it off.

Reactions

Ashish Chaturvedi of HFS Research sees the main benefit in workflows that span multiple services, such as S3, Lambda, DynamoDB and API Gateway. There's also less clutter in shared accounts. Many customers, he says, have found a forgotten test bucket on their bill months later. Patel sees the biggest win for coding agents: their loop of writing, running, reading errors and fixing shrinks “from minutes to seconds” per pass, and agents can experiment freely without creating anything expensive in a real account. Chaturvedi calls this a path to “safer agent adoption” for IT leaders. AWS plans to show more details at its re:Invent conference.

The bigger picture

The timing is no accident. According to GeekWire, LocalStack, the best-known third-party AWS emulator, tied its free version to a user account this year and restricted it to non-commercial use. A free, public-domain emulator straight from AWS, with publicly visible fidelity scores, is a direct response. It also fits an era in which AI agents run hundreds of test passes an hour.

Still, the emulator gives you fast feedback, but it doesn't replace final testing. You still need to test security, permissions and failure behavior against real AWS. If you want to use it, check the fidelity scores for every service you rely on, remove real credentials from your test jobs and turn off telemetry if you need to.

And the promise that “no human reviewed the code” is only as solid as the tests and gates around it. So the headline matters less than the public test suite, which lets you verify what the emulator can and can't do. The project is a large-scale real-world test of whether agent-generated software at this scale is reliable enough for developers' day-to-day work.