On November 11, 2026, Amazon Web Services (AWS) made AWS Emulator generally available, a tool that lets you run AWS APIs in a local environment. It can be used without an AWS account and carries no additional service charges. Standard charges still apply if you deploy resources to real AWS. AWS also revealed that all of the emulator's source code was written by autonomous AI agents, and that the human development team neither wrote nor reviewed any of it.
With AWS Emulator, you no longer need to deploy to the cloud every time you change an application. You can repeat functional checks on your own PC or in a continuous integration (CI) environment. However, it is not guaranteed to behave exactly like real AWS, and API support and reproduction accuracy vary by service. Verification involving access permissions and load in particular still needs to be done on real AWS.
Reproducing AWS API calls locally
AWS Emulator is an emulator that accepts AWS API requests locally and processes them in place of the actual cloud services. By switching the endpoint that the AWS CLI and each language's AWS SDK connect to via an environment variable, you can use it without changing your application code. The default endpoint is https://127.0.0.1:9297, and it uses HTTPS.
For example, an application that uses Amazon DynamoDB can try out a full sequence of operations locally: creating a table, writing data, and reading it back. AI coding agents can use the same environment, so they can repeat the cycle of generating code, checking behavior, and fixing it without deploying to real AWS. This assumes, however, that the target API is implemented and that the required processing works the same way it does on AWS.
Each time it starts, the emulator generates a dedicated access key, certificate, and configuration file. Access keys begin with EMULATOR, and as a rule only requests signed with the key generated during that run are accepted. Some SDKs also require configuration to trust the self-signed certificate. Resource state is held in memory and erased when the emulator stops.
According to the AWS official documentation, API requests, responses, and resource data are not sent to AWS. However, sending of anonymized usage and error data is enabled by default, and it can be disabled. Note that the emulator validating its own access keys is not the same as evaluating permissions based on AWS IAM policies.
AI agents wrote all the code, with quality verified against real AWS
The other notable point in this announcement is the development method. Matthew Goldberg, a senior principal engineer at AWS, explained in an official Amazon article that autonomous AI agents wrote all of AWS Emulator's code. The human development team neither wrote nor reviewed code; instead, it built the mechanisms that let the agents work autonomously, along with quality-control processes. In Japan, ITmedia has also covered the story, focusing on this development approach.
The project started from an idea: if an AI agent were given the AWS API specifications and access to the actual cloud environment, it might be able to build a program that reproduces the same behavior. When Goldberg instructed Kiro, an initial implementation of Amazon SQS was complete in about 15 minutes. By that weekend, a rough prototype covering all of AWS was ready. Releasing it as a real product, however, required additional development to ensure quality and safety.
In full-scale development, the AI agents were split into three teams with different roles. The first team creates tests from AWS API models and confirms the correct results on real AWS. The second team runs the same tests on the emulator and detects differences in behavior from real AWS. The third team fixes the problems that are found and verifies the fixes.
The emulator in its earliest stage was an empty server that could merely accept requests corresponding to 438 AWS API models. From there, agents implemented each service's processing and corrected differences from real AWS. Before being merged, fix code is checked for build success, coding standards, security, and impact on existing features, and it is sent back if problems are found. According to AWS, hundreds of agents work in parallel, resolving thousands of issues per day.
The code is managed in AWS CodeCommit and distributed after building and retesting through AWS CodePipeline. The source code for public release is pushed to GitHub as the last step of that process. In other words, instead of humans reviewing individual pieces of code, the development setup puts automated tests using real AWS as the benchmark, together with inspections by multiple AI agents, at the center of quality control.
API coverage and compatibility with real AWS are different things
One thing to watch when using AWS Emulator is that support for an API model is not the same as being able to reproduce the behavior of real AWS. An API model defines the format of requests and responses, and it does not guarantee that every operation it contains is implemented. Calling an unimplemented operation returns an HTTP 501 and a NotImplemented error.
AWS calls the degree of match with the real services "fidelity" and evaluates it through comparison tests. The tests use the SDK to run a sequence of operations and check not only return values but also changes in resource state, side effects, and errors for invalid requests. However, not every behavior is covered.
The items developers should check are summarized below.
| Verification item | What you can confirm locally | What needs verification on real AWS |
|---|---|---|
| API support | Whether the required operations are implemented | Behavior of unimplemented or unverified operations |
| Processing fidelity | Return values, state changes, side effects, errors | Behavior not confirmed by comparison tests |
| Access permissions | Emulator-specific authentication | Allow/deny decisions by IAM and resource-based policies |
| Data persistence | In-memory state while running | Long-term storage, state retention after restart |
| Load and configuration | Basic operation on a single instance | Load, long-running operation, cross-account and cross-region behavior |
According to AWS's explanation of fidelity, the APIs for which behavior closest to real AWS can currently be reproduced are control plane APIs, which handle creating, reading, updating, and deleting resources. Support for data plane APIs, such as reading and writing objects, and for Infrastructure as Code (IaC) tools such as CloudFormation, Terraform, and AWS CDK varies by service.
Each service's fidelity score indicates how many of the prepared comparison tests it passed. It is not a compatibility rate for the service as a whole. AWS publishes scores and test versions with each release, so when adopting the tool you need to check whether the operations your application uses have been verified. If the denominator grows because test items are added, the score can drop even when the emulator's functionality has improved.
Access control is especially important. AWS Emulator does not evaluate IAM policies or resource-based policies the way real AWS does, so operations that would be denied in production may succeed locally. In addition, one instance is, as a rule, designed for a single AWS account and Region, so if you want to try multiple Regions you need to start a separate instance on a different port for each. Actual cross-Region communication and cross-account access are not reproduced, and long-running operation and load testing have not been verified.
Packages for Linux; macOS and Windows run via Docker
AWS Emulator is implemented in Rust, and for Linux, RPM and Debian packages are provided for x86_64 and Arm64. The required glibc version is 2.17 or later. On macOS and Windows it runs on Docker, but no prebuilt container image is distributed, so users must build one with the official Dockerfile.
For the Rust SDK, an embedded mode is also available that runs the emulator directly inside the test process. There is no need to start a separate server process, and each test can use an instance with its own independent state. However, because embedded mode compiles the emulator's code together with the test program, the initial build load is heavy.
The README of the official GitHub repository asks for at least 100 GB of free disk space for the target/ directory when building from source. Even in Rust embedded mode, you should expect a build of similar scale on the first cargo test. This is a requirement for building from source, and does not mean that running the packaged version needs 100 GB of free space.
The source code is released under CC0 1.0, but third-party code in the vendor/ directory is covered by the Apache License 2.0. On GitHub, in addition to the fidelity scores for each release, unsupported features and fixed issues are also published.
By moving tests of API calls and basic workflows during development to the local machine, AWS Emulator could reduce the number of deployments to AWS and the waiting time during development. It also pairs well with the fast trial and error of AI coding agents, though gaps in compatibility with real AWS remain. When adopting it, check the implementation status of the APIs you use and the comparison test results, and verify permissions, load, and production behavior on real AWS.