AWS Emulator: Test AWS Applications Locally Without Deploying to the Cloud

A coding agent can create an S3 bucket, wire up a queue, or add a DynamoDB integration in minutes. But if every experiment requires a real cloud deployment, the feedback loop becomes slow and expensive.

On November 11, 2026, AWS announced AWS Emulator, a local emulator for AWS APIs. It lets the AWS CLI, AWS SDKs and coding agents send familiar requests to a local HTTPS endpoint instead of deploying resources to an AWS account.

This is a fresh developer-tools launch rather than a long-established GitHub project suddenly becoming popular. The official announcement is the strongest trend signal: AWS is explicitly positioning the emulator for local development, CI, and agent-driven testing.

What AWS Emulator does

AWS Emulator runs on your computer or in a CI environment. Your application continues to use the AWS SDK or CLI, but the endpoint is redirected to the emulator.

That means you can test a workflow such as:

Create a DynamoDB table.
Write and read an item.
Create an S3 bucket and upload an object.
Send and receive an SQS message.
Check how your application handles an invalid request.

The emulator keeps resource state in memory while it is running. Each instance gets its own port, credentials and state, which helps keep parallel test runs isolated.

AWS says the emulator is generated from published AWS API models, the same models used by AWS SDKs. For operations it supports, it aims to return the same successful results and error shapes as AWS. Unsupported operations return HTTP 501 Not Implemented.

It has no additional service fee. You pay for AWS resources when you deploy to AWS, not for using the emulator locally.

The unusual part: agents built the emulator

AWS's engineering write-up describes a three-team agent workflow:

Test writers create scenarios from AWS API models and verify them against real AWS.
Issue finders replay those scenarios against the emulator and report mismatches.
Fixers take individual issues and send changes through a merge gate.

The gate checks whether changes build, pass tests, meet coding and security checks, and preserve fidelity with AWS. The tests can then be replayed without calling AWS again.

This is interesting beyond the emulator itself. The important engineering idea is not simply "let agents write a cloud emulator." It is to give agents a precise specification, a reference implementation, a replayable test suite, bounded tasks, and a strict merge gate.

AWS says the source is published under the CC0 1.0 Universal public-domain dedication. Check the repository for third-party components and their individual licences.

Install it on Linux

The AWS News Blog's getting-started example uses the Linux RPM package:

PKG=https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest sudo dnf install -y $PKG/aws-emulator-x86_64.rpm

Start the emulator:

aws-emulator

The local process listens on HTTPS at 127.0.0.1:9297 by default.

On macOS and Windows, AWS currently documents running the emulator in Docker. Its announcement says to build an image from the short Dockerfile in the documentation; AWS does not publish a ready-made image for this workflow.

Point your AWS CLI or SDK at the local endpoint

When the emulator starts, it creates temporary credentials, a config file and a certificate under your home directory, typically in:

~/.aws/emulator/9297/

In the shell where you run your application, use the generated files:

export AWS_ENDPOINT_URL=https://127.0.0.1:9297 export AWS_SHARED_CREDENTIALS_FILE=~/.aws/emulator/9297/emulator_credentials export AWS_CONFIG_FILE=~/.aws/emulator/9297/config export AWS_CA_BUNDLE=~/.aws/emulator/9297/ca.pem export AWS_EC2_METADATA_DISABLED=true export AWS_DISABLE_HOST_PREFIX_INJECTION=true export AWS_REGION=us-east-1 export AWS_DEFAULT_REGION=us-east-1 # Remove environment credentials that could point to real AWS unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE

Do not skip the final line. Environment credentials can take precedence over the emulator's generated credentials. The emulator rejects requests signed with the wrong keys, but explicitly removing real credentials makes the test boundary easier to reason about.

Check that the local process is healthy:

curl --cacert ~/.aws/emulator/9297/ca.pem \ https://127.0.0.1:9297/__admin/health

Now use familiar AWS CLI commands:

aws s3 mb s3://local-getting-started echo "hello from the emulator" > hello.txt aws s3 cp hello.txt s3://local-getting-started/ aws s3 ls s3://local-getting-started/

Your application code can remain the same; the environment determines whether its AWS requests go to the local emulator or to AWS.

Important limitations

AWS Emulator is a development and testing tool, not a production cloud replacement.

API coverage is not universal. Unsupported operations return 501. Check the release's fidelity report before depending on a service.
State is temporary. Resource state stays in memory until the emulator stops. Do not treat it as durable storage.
Use one Region per instance. The documentation recommends a separate emulator instance when you need to test multiple Regions.
It is not a substitute for cloud integration tests. IAM policies, networking, quotas, service integrations and real deployment behaviour still need validation in AWS.
Keep the security boundary local. SigV4 request signing is enabled by default. Avoid turning authentication off unless you understand the implications.

The AWS documentation also publishes a fidelity report, which is more useful than assuming that every API behaves exactly like the real service.

AWS Emulator vs LocalStack vs Moto

These tools solve overlapping but different problems.

Tool	Best starting point	What to check
AWS Emulator	Testing AWS API behaviour with the official AWS CLI and SDKs	Supported operations, fidelity and current platform support
LocalStack	A broader local AWS development environment	Current distribution, authentication requirements and feature tier
Moto	Mocking AWS services in Python tests	Service coverage and the level of behaviour your tests require
Testcontainers	Managing disposable dependencies during integration tests	Whether the container/module supports the services you need

I would not replace an existing LocalStack or Moto setup just because AWS Emulator is new. Pick a representative workflow, run the same tests against both, and compare API coverage, error behaviour, startup, CI integration and maintenance.

Where it fits in an AI coding workflow

This is particularly useful when an agent is changing infrastructure code or writing application logic that calls AWS.

Instead of allowing every experiment to create real cloud resources, give the agent a local endpoint and a test suite. It can make a change, run the tests, inspect failures, and iterate without waiting for a deployment.

Keep the final deployment and integration checks in a real AWS environment. Local emulation should make the feedback loop faster, not create false confidence that production behaviour has been fully tested.