AWS releases a free local emulator of its cloud, written by AI agents

The repository README says you use it to test software without calling AWS, on your own machine, on a development server or in continuous integration, and that you do not need an AWS account. It has no graphical interface. After you start it, you point the CLI or an SDK at its endpoint with environment variables. In embedded mode you pass its HTTP client to the SDK instead[3].

On Linux the blog uses an RPM or Debian package. On macOS and Windows you build a Docker image from a short Dockerfile in the documentation and run that. AWS does not publish a ready-made image. You can also build from source[1]. The README says a source build is supported on Linux, for x86_64 and aarch64, and that Windows and macOS use the Docker path[3].

When the emulator starts, the blog says, it writes its own credentials, a config file and a certificate to ~/.aws/emulator/9297/. It serves HTTPS on 127.0.0.1:9297, so only that computer can reach it. You set AWS_ENDPOINT_URL to https://127.0.0.1:9297, and you point AWS_SHARED_CREDENTIALS_FILE and AWS_CONFIG_FILE at the files it wrote. The blog's example also sets AWS_EC2_METADATA_DISABLED and AWS_DISABLE_HOST_PREFIX_INJECTION, sets the region to us-east-1, and unsets any real access key, secret, session token or profile. It generates new keys on each start. Those access key IDs begin with EMULATOR, and it rejects a request signed with any other key. A check of caller identity returns a single account, 000000000000[1].

Application code stays as it is. The blog's example is a test that creates a DynamoDB table, writes an item and reads it back, on the machine, with no deployment. Put the same variables in the script that runs an existing suite, and that suite talks to the emulator. Some SDKs need an extra setting to trust its certificate. The blog names a trust store for the AWS SDK for Java[1].

Embedded mode is the in-process option, and the blog says it is available for the AWS SDK for Rust. The test creates the emulator and wires its HTTP client into the SDK. Each instance keeps its own state, so tests do not share buckets, tables or queues[1]. The README says a coding agent can install a skill named aws-emulator with aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1, and that this needs AWS CLI version 2.35.0 or later[3].

On the local process, every request has to be signed with Signature Version 4. A script can wait on /__admin/health on the same port. By default the emulator sends anonymous usage and error data, and you can turn that off[1].

Goldberg traces the project to a weekend experiment. Researchers at Anthropic had shown agents building a C compiler, he writes, so he gave Kiro a short prompt: write tests from the AWS CLI, iterate until they pass against real AWS, then build an in-memory implementation that those same tests pass against. He says Kiro came back in 15 minutes with a passable Amazon SQS. Over that weekend a refined prompt produced a rough version of the rest of AWS, with obvious gaps, and his team started testing its own software against it that Monday[2]. Callaway told The New Stack his first reaction was, "Are we sure this is a good idea?"[5]

AWS Emulator, Goldberg writes, is built by three teams of agents. He splits the work that way because the agents have more success on bounded tasks, and he writes, "I think agents also need coloring books."[2]

The first team keeps the fidelity tests. A test is a workflow, such as creating an SQS queue, sending a message, receiving it, acknowledging it and deleting the queue. Agents write the tests from the public API models and check each one against real AWS before submitting it. He says there are tens of thousands of these tests, the suite keeps growing, and a test can be rerun without calling AWS again[2].

The blog says what counts as a pass. The emulator has to match AWS on every call, including the status code, the body and the exact error code and message, and on the resources and data the workflow creates. Each release publishes a score for each service, as k of n. Adding tests can lower a score even while the emulator improves. The tests, including the ones that do not pass yet, are public in the aws-emulator-evaluation-suite repository[1].

The second team replays those tests on the emulator and files an issue for each gap. Goldberg says they are told to group failures that may share a cause[2]. The blog's account of the group that files gaps adds a second check: it compares the emulator's code, statically, with the published Smithy models[1].

The third team takes one issue at a time. It checks out the code, finds the cause and edits until that issue is addressed, then sends the change through a merge gate. Goldberg writes that the gate blocks anything that does not compile. Agents review the change against coding standards, check that it is secure, and check that fidelity did not regress. A failed check goes back to the agent. If they all pass, it merges to mainline. He writes that hundreds of agents, working at once, have been fixing thousands of issues a day, and that without the gate the team would not trust what the agents build[2]. GeekWire reports the same three teams, and says they run on Amazon Bedrock AgentCore[4].

The blog says the agents run on Amazon Bedrock AgentCore Runtime Instances, with AWS CodePipeline and AWS CodeCommit. An independent security agent reviews a change adversarially while the fix is in progress, and again in the release pipeline before anything ships. A push starts a pipeline run that executes the fidelity tests before the change is published to the public GitHub repository[1].

Goldberg says CodeCommit is the agents' main repository. Commits typically stack, and are built and retested, before they merge to a release branch. The pipeline then packages a binary. Only at the end does it also publish the code to GitHub. Issues the agents have fixed sit in issues/things-that-now-work. The backlog is issues/things-that-do-not-work[2]. The README lists those same two directories, and says the repository does not take pull requests[3].

Callaway told The New Stack that outside contributions stop at issues. "We're not going to take pull requests on the project at all," he said. "The agents will be doing that. We will take issues from customers." Of the engineers, he said, "We don't edit it. We don't modify it." If the code is wrong, they trace it to the agent and change the agent. If the docs do not tell the truth, he said, the cloud is the source of truth[5].

He expects support for a new service to follow in "days, not weeks, not months", and he said the team has not yet seen how that goes with the project in public. The first iterations, he said, "did not have as aggressive a sandbox as they needed to", and there was early concern the agents might look at the source of internal services, such as Aurora, to work out an implementation. He also said the team spent a lot of time reassuring executives that the framework was not going to "go rogue"[5].

The blog says not to use the emulator to test whether an application is secure. It does not evaluate IAM policies or resource-based policies the way AWS does, so a request AWS would deny can succeed locally. Keep real credentials out of test jobs, it says, and test security settings, and the whole application, on AWS before production. Each emulator acts as a single account, with no cross-account or cross-region behaviour. How closely it matches AWS varies by service and feature, and the blog points readers to the fidelity scores. If an operation is not implemented, the emulator returns HTTP 501, so the test fails straight away[1]. The README says it is for building and testing, not for production workloads and not for security testing[3].

GeekWire reports that Devin Pratt, an IDC analyst, told InfoWorld the emulator does not yet simulate throttling, outages or differences in which services and features are available by region, and that it does not sandbox the code it runs. The known gaps, GeekWire says, are public in the GitHub folder things-that-do-not-work[4].

Callaway told The New Stack the emulator "really was built for the purposes of testing coverage." He gave the example of a SQL query that does not come back with the right results, because, as he put it, there is no database[5].

The README states the licence as CC0 1.0 Universal, except the code in vendor/, which is under the Apache License 2.0[3].

Goldberg gives one reason. An earlier run of the agents, he writes, decided to build their own Python interpreter so the emulator could run Lambda functions. The team later told them to reuse existing libraries. "The insights we've gained from this history were the main motivation in our decision to release this software as a public dedication under the Creative Commons CC0 license," he writes[2].

Callaway gave The New Stack a different reason. He said AWS was not sure it could copyright work the agents had produced, and did not want to assert copyright where none may exist[5].

GeekWire says other AWS emulators exist, most notably LocalStack, which this year put its free version behind an account requirement and limited it to non-commercial use. AWS, GeekWire writes, released its emulator for free under CC0, which it calls a public domain dedication, with the full commit history on GitHub[4].

GeekWire says coding agents such as Kiro and Claude Code write code faster than a team can test it against the real cloud. Agents check their work by running it and reading the result, over and over, and doing that in the cloud adds delay and cost. The emulator is that loop on the developer's machine, without a network connection and without paying for the real cloud[4]. The blog makes the same point for someone working with Kiro or Claude Code: the agent can create resources, check the result and try again without waiting on a deployment in a region[1].

The New Stack says the team also wanted agents to test code against AWS services without handing over AWS credentials[5]. The blog's warning sits beside that. It says not to use the emulator as a security test, and to keep real credentials out of the test job[1]. Callaway told The New Stack the running emulator does not call a language model at all[5].

Swami Sivasubramanian, AWS vice president of agentic AI and emerging tech, wrote this in a guest post on Werner Vogels' blog, as GeekWire quotes him. "When agents write the code and check their own work, the engineer's job is to give them room to work on their own and to build the specs, tests, and merge gates that decide when that work is correct."[4] Goldberg describes that job on this project. His team built the guardrails, he writes, and the agents write the code inside them[2].

GeekWire says AWS will share more at its coming re:Invent conference. The New Stack says the conference starts on 30 November[4][5].