AWS Emulator Lets Coding Agents Test Cloud Operations Locally Before They Deploy

Coding agents write code fast. Testing that code against the real cloud? That’s still slow. Every change means a deployment, a wait, and a small cloud bill for the privilege of finding out the agent got a DynamoDB call wrong. On November 11, AWS decided that loop needed shortening, and it shipped AWS Emulator: a local stand-in for its own APIs that runs on your machine, costs nothing, and doesn’t even ask for an AWS account.

The idea is simple enough. Your AWS CLI, your SDKs and your coding agents talk to the emulator over a local HTTPS endpoint, using the exact same APIs they’d use in the cloud. The difference is that nothing leaves your laptop. An agent can create a table, write an item, read it back, spot its mistake and rewrite the code, all in seconds, without a deployment to a Region anywhere in the middle.

One Endpoint, Zero Changes to Your Code

Setup is refreshingly dull, which is a compliment. On Linux you install an RPM or Debian package; on macOS and Windows you run it in Docker. Start it, and the emulator serves HTTPS on 127.0.0.1:9297, generates its own credentials, config file and certificate, and waits. You point your tools at it with environment variables, starting with AWS_ENDPOINT_URL, and your application code stays exactly as it was. The source sits in the aws/aws-emulator repository on GitHub, where you can also build it yourself.

A few design choices tell you who this was built for. The emulator is written in Rust, so it stays light on CPU and memory while it runs next to your editor. Its fake account is always 000000000000, and its access keys literally start with the word EMULATOR, so there’s no way to confuse them with real keys or bill yourself by accident. State lives in memory and vanishes when you stop the process. Each run starts clean.

There’s also an embedded mode for Rust tests: you add the aws-emulator-embedded crate as a dev-dependency, and each test spins up its own isolated instance in-process. No endpoint, no certificate, no shared buckets between tests. And if your workflow runs through an agent, AWS offers an installable aws-emulator skill (it needs AWS CLI 2.35.0 or later) so the agent can set the whole thing up for you.

Coverage is broad because of how the thing is generated. The emulator is built from the published AWS API models, the same Smithy models the official SDKs are built from: more than 400 models covering over 200 services. That’s why requests and error messages have the same shape as the real cloud. When an operation isn’t implemented yet, the emulator doesn’t fake success. It returns HTTP 501, and your test fails on the spot, loudly, which is exactly what you want from a test double.

The Emulator Was Written by Agents, Too

Here’s the part AWS is clearly proudest of. The whole project started as a weekend experiment: senior principal engineer Matthew Goldberg prompted Amazon’s Kiro coding agent, and roughly 15 minutes later he had a passable emulator of Amazon SQS. In a companion post, Goldberg wrote the line that’s now doing the rounds: “The emulator was written entirely by autonomous agents. Our team hasn’t written or reviewed any of the code.”

That isn’t a one-off stunt. Agents maintain the emulator on an ongoing basis, running on Amazon Bedrock AgentCore with CodeCommit and CodePipeline in the loop. One group hunts for gaps, comparing emulator responses against real AWS and checking the code against the published models, then files an issue for each gap it finds. Another group picks up an issue, writes tests, implements the behavior and reviews the change. An independent security agent reviews changes adversarially before anything ships. The agents are productive enough that the pattern is spreading: Cursor now builds and hosts live web apps from a single prompt, and Meta’s Muse Ember is a small model tuned for exactly this kind of high-volume agent work. Agents aren’t just writing app code anymore. They’re writing the infrastructure the app code gets tested against.

How does AWS know the imitation behaves? Fidelity tests. Each one is a short workflow, store an object, read it, delete it, first verified against real AWS. The emulator only passes if it matches AWS on every call: the status code, the body, the exact error code and message, and the resources the workflow creates. With each release, AWS publishes a per-service score, written as k of n, and the full test suite is public on GitHub, including the tests that don’t pass yet. There’s even a folder in the repo called “things-that-do-not-work,” which might be the most honest piece of documentation a cloud vendor has ever shipped. Fair warning from AWS itself, though: a score can dip when new tests land, even while the emulator improves.

Where the Imitation Stops

So can you skip real AWS testing altogether? No, and AWS says so in plain language. The emulator doesn’t evaluate IAM or resource-based policies the way AWS does, which means a request the real cloud would deny might sail through locally. Don’t use it to test whether your application is secure. Keep real credentials out of your test jobs, and run your security settings against actual AWS before production.

Other limits are structural. One emulator instance plays one account, with no cross-account and no cross-Region behavior, so anything that depends on Regions talking to each other is out of scope. Fidelity varies by service and feature, which is why those published scores matter more than the headline coverage number. Analysts have pointed at further gaps: IDC’s Devin Pratt noted it doesn’t yet simulate throttling or outages, and it doesn’t sandbox the code it runs. It’s a tool for building and functional testing on your machine, a dev server or a CI pipeline, not for production workloads.

None of that undercuts what shipped this week. The code is public under a CC0 public-domain dedication (the vendored bits stay Apache 2.0), the repo takes bug reports through GitHub Issues rather than pull requests, and there’s no service fee at all. You pay for AWS resources only when you deploy for real. AWS says there’s more to share at re:Invent. Until then, the fastest AWS test run you’ll ever do is the one that never leaves your laptop.