AWS launches AWS Emulator for testing applications against AWS locally

AWS Emulator puts the AWS API on your laptop

AWS announced AWS Emulator on its News Blog in a post by Daniel Abib dated November 11, 2026. It is a local emulator of Amazon Web Services that runs on your own machine. The AWS CLI, the AWS SDKs and coding agents talk to it over a local HTTPS endpoint, using the same AWS APIs they would call in the cloud. AWS says the tool carries no additional service fee. You pay only for AWS resources when you deploy on AWS. The source is published on GitHub. On Linux you install it from an RPM or Debian package. On macOS and Windows you run it in Docker, and AWS does not publish a ready-made image, so you build one from a short Dockerfile in the documentation.

How a local run works

You install the package, start the `aws-emulator` command and point your tools at the local endpoint. On start, the emulator generates its own credentials, a config file and a certificate, and writes them to `~/.aws/emulator/9297/`. It serves HTTPS on `127.0.0.1:9297`, so only your own computer can reach it. You then set a handful of environment variables, such as `AWS_ENDPOINT_URL`, and unset any variable that could supply real AWS credentials. Your application code stays unchanged.

The emulator makes new keys on every start. Its access key IDs begin with `EMULATOR`, so nobody mistakes them for real keys, and it rejects requests signed with any other keys. It uses a single account, `000000000000`. In the walkthrough, the author creates an S3 bucket, copies an object, and then asks the Kiro coding agent to create an Amazon DynamoDB table, write an item and read it back, all against the local endpoint instead of a real account. An existing test suite can use the same setup: start the emulator, set the variables in the test script, and run the tests as usual.

Embedded mode for fast, isolated tests

For tests there is a second option. An embedded mode lets you create the emulator inside the test process and wire it into the SDK through its HTTP client. Each embedded instance keeps its own state, so tests do not share buckets, tables or queues, and many can run in parallel. At launch, embedded mode is available for the AWS SDK for Rust, through the `aws-emulator-embedded` crate. Some SDKs need an extra setting to trust the emulator certificate when it runs as a separate process. The post names the trust store of the AWS SDK for Java as one example. As a process, the emulator requires SigV4 signing on every request and exposes a `/__admin/health` endpoint, so a script or container can wait until it is ready.

How AWS measures fidelity

An emulator helps only if a test that passes locally would also pass on AWS. AWS therefore uses fidelity tests. Each one is a short program that runs a workflow through an AWS SDK and asserts how AWS behaves. AWS checks every fidelity test against real AWS. A test passes only if the emulator matches AWS on every response, including the status code, the body, the exact error code and message, and the resources the workflow creates. With each release, AWS publishes a score per service as k of n. The test set is public in the aws-emulator-evaluation-suite repository, including tests that do not pass yet. AWS also warns that a score can fall when new tests are added, even while the emulator improves. If an operation is not implemented, the emulator returns HTTP 501, so the test fails at once instead of passing by accident.

Built and reviewed by agents

AWS says agents build and maintain the emulator from the AWS API models, using Amazon Bedrock AgentCore Runtime Instances, AWS CodePipeline and AWS CodeCommit. One group of agents looks for gaps and files an issue for each. Another group writes tests, implements the behavior and reviews the change. A push then triggers a pipeline run that executes the fidelity tests before anything reaches the public repository. An independent security agent reviews changes adversarially during the fix and again in the release pipeline. These are AWS's own statements about its process. The post gives no independent audit of them.

Limits you should plan for

The post is direct about limits. The emulator does not evaluate IAM policies or resource-based policies the way AWS does, so a request that AWS denies might succeed locally. AWS says not to use the emulator to test whether your application is secure. Each emulator acts as a single account, with no cross-account or cross-Region behavior. How closely it matches AWS varies by service and feature, so check the fidelity scores for the services you use. By default the emulator sends anonymous usage and error data, and you can turn that off. One reader, in a single comment on the post, raises a certificate regenerated on each start and a fault in how signed-chunk S3 uploads from the .NET SDK are stored. These are unverified user reports, not AWS statements. Treat them as unconfirmed until AWS responds.

What it means for developers

For teams that test against real AWS accounts today, a faithful local endpoint can cut cost and wait time, and it gives coding agents a safe place to try things and iterate. The cost is that local green results are not proof of production behavior, especially for security rules. Keep real credentials out of test jobs, and run your final checks on AWS before release.