AWS releases a free emulator to test cloud apps locally

Amazon Web Services released AWS Emulator on November 11, a free tool for testing applications on a developer’s own computer before deploying them to the cloud. It works without an AWS account. Requests handled by the emulator incur no AWS service charges. Resources deployed to the actual cloud are billed as usual.

An application built for AWS can keep its existing software development kit and send test requests to the emulator instead. It can run on a laptop, a development server or in continuous integration, where teams run checks automatically as their code changes. AWS says autonomous AI agents wrote the emulator’s code.

Testing what happens after a bucket is created

The AWS user guide illustrates a test that creates an Amazon S3 bucket and checks that it appears in the bucket list. The second request checks that the result of the first is still there. Another example checks whether DynamoDB rejects a table name that is too short with the same input error the cloud service would return. Resources created in these tests stay in memory for the life of the emulator and are cleared when it stops.

AWS ships Linux packages in RPM and Debian formats. On macOS and Windows, developers can run the emulator in a Docker image built from a file supplied by AWS. Tests written with the AWS SDK for Rust can also run the emulator inside the test process. Each instance keeps its own state, so tests running in parallel can create separate resources. This option compiles the emulator as part of the project’s first test build.

AWS publishes test results with each release

AWS Vice President Swami Sivasubramanian said in a launch-day article that the emulator draws on more than 400 API models covering over 200 AWS services. Those models describe the requests and responses for a service. The depth of the implementation varies. AWS says the emulator currently comes closest to the cloud for operations that manage resources, such as creating and listing S3 buckets. Coverage for operations that work on the data itself, such as reading or writing objects, also depends on the service. So does support for tools that define infrastructure in code.

AWS reports a fidelity score for each service with every release. It counts how many of the service’s published test scenarios the emulator passes. A scenario can span several requests, and passing means matching both the responses and what happens to the resources afterward. If AWS returns an error, the test checks for the same error locally. AWS also publishes tests the emulator still fails. Comparisons between releases use the same version of the test suite, since AWS adds scenarios over time.

If an application relies on behavior absent from the published tests, its developers cannot establish a match from the score alone. The user guide describes comparing that workflow on the emulator and on AWS. Regional differences and access policies also require checks in the actual environment. AWS describes the emulator as a development and testing tool and directs users to the cloud for production workloads and security validation.

How AWS checks code written by agents

Matthew Goldberg, a senior principal engineer on the AWS Developer Tools team, said the project team neither wrote nor reviewed the emulator code itself. Engineers designed the process used to check it. In Goldberg’s account, one group of agents creates test scenarios from public API specifications and checks the expected results against AWS. A second group runs those tests on the emulator and records differences. A third group works on the resulting fixes.

AWS says a change must build and pass automated checks, including tests for regressions, before it can be merged. Changes are built and tested again before AWS packages a release. The repository includes the development history and records of outstanding differences. AWS released the emulator under CC0 1.0, with Apache 2.0 covering code in its vendor directory. The repository takes bug reports through GitHub Issues and does not accept pull requests.