AWS Emulator brings the AWS cloud to your laptop

The news matters because code agents work in a loop: they write, execute and read the result before deciding the next step. With infrastructure inside that loop, the agent tests AWS calls in seconds.

In this article you will see:

• What the AWS Emulator is and how it works
• How to install and point the AWS CLI to the local endpoint
• How AWS measures fidelity and what the limits are
• What changes for people programming with agents

What is the AWS Emulator, the local AWS emulator

The AWS Emulator is an open source emulator of Amazon Web Services APIs. The AWS CLI, SDKs and your code agents talk to it via a local HTTPS endpoint, using the same APIs they would use in the cloud.

According to AWS, application code stays the same. A test that creates a table in Amazon DynamoDB, writes an item and reads it back is the same test, only it runs on your laptop and without a deploy.

The emulator is written in Rust to use little CPU and memory. It supports the APIs of services that have a published model in the AWS API models repository, the same ones used by the SDKs, and therefore requests and errors have the same format as the cloud.

AWS also states that the project has no additional fee: you only pay for the resources you create in AWS when you deploy. The code is in the repository aws/aws-emulator on GitHub.

How to install the AWS Emulator and point the AWS CLI

On Linux, installation is done via RPM or Debian package, which adds the aws-emulator command to the system. On macOS and Windows, AWS recommends running the emulator in Docker. You can also compile from source.

On startup, the emulator generates its own credentials, a configuration file and a certificate, saved in ~/.aws/emulator/9297/. Then you set environment variables so the SDK talks to your laptop instead of AWS.

$ aws-emulator

The keys change on each startup and the access IDs start with EMULATOR, which avoids confusion with real keys. The emulator rejects requests signed with any other key and uses a single account, 000000000000.

When running as a local process, it requires SigV4 signature on all requests, as AWS does. There is also the /__admin/health endpoint, which lets a script or container wait for the emulator to be ready before running tests.

By default, the emulator sends anonymous usage and error data, and AWS says it is possible to disable this.

How AWS measures the fidelity of the AWS Emulator

An emulator is only useful if a test that passes on it also passes on AWS. For that reason the company uses fidelity tests: short programs that use an SDK to run a flow, such as store, read and delete an object, and check how AWS behaves.

Each test is verified against real AWS. It only passes if the emulator matches the cloud on all calls, including status code, response body, error code and message, as well as the resources created.

With each release, AWS publishes how many tests pass per service, in k of n format. For example, 40 out of 50 means 40 of the 50 tests for that service pass. The test suite is public, including those that still fail.

AWS itself asks for caution when reading: when tests are added, the score can drop even as the emulator improves. If an operation does not exist, it returns HTTP 501 and the test fails immediately.

Built by agents: how the AWS Emulator was built

The emulator is built and maintained by agents, from AWS API models, using Amazon Bedrock AgentCore, AWS CodePipeline and AWS CodeCommit. One group of agents looks for gaps by comparing responses with real AWS and opens an issue for each one.

Another group picks up the issue, writes tests, implements the behavior and reviews the change. An independent security agent reviews the changes adversarially, during the fix and again in the release pipeline.

In the text published on November 11 on the All Things Distributed blog, Amazon CTO Werner Vogels publishes a guest article by Swami Sivasubramanian. The text states that all of the emulator code was written and tested by agents and that it is built from more than 400 API models, covering more than 200 AWS services.

The same text says the code is released under CC0, a dedication to the public domain, and that the commit history and issues opened by agents are public, including the folder with behaviors that still do not match real AWS.

Limits of the AWS Emulator at launch

AWS is direct about what the emulator does not do. It does not evaluate IAM policies like the cloud and, therefore, a request that AWS would deny may work in the emulator. The company recommends not using it to test whether the application is secure.

Each emulator works as a single account, with no cross account or cross region behavior. Coverage varies by service and resource, so it is worth checking the fidelity notes in the documentation for the services you use.

Another official recommendation: keep real credentials out of the test jobs environment and validate security configurations and the entire application on AWS before going to production.

How to test the AWS Emulator today with your code agent

The official documentation describes a path for agents: install the skill aws-emulator and let the code agent install, start and connect the emulator. AWS cites agents like Kiro and Claude Code as use cases.

If you want to organize this kind of routine, it is worth reading how to automate repository tasks with GitHub Agentic Workflows, since local tests combine well with CI automations.

For the interface layer, the guide on testing web apps with the Playwright CLI and AI agents shows how to give the agent a browser. Front end debugging is covered in the text about the Chrome DevTools MCP.