AWS Emulator is here. Your laptop can now pretend to be the cloud.

On 11 November 2026, Amazon Web Services released AWS Emulator, a free local copy of more than 200 AWS services. No AWS account, no deployment, no bill for the test itself. You point the same SDK and CLI calls at your own machine, and they come back in milliseconds.

For years, the honest answer to “how do I test this AWS code without touching the cloud?” was a compromise. You could mock the calls, and learn nothing about the real API shapes. You could spin up a test account, and wait for a deployment, pay for the resources, then remember to tear them down. Or you could use a third-party emulator, and accept that it was not AWS itself, and that its coverage stopped somewhere inconvenient.

AWS Emulator changes the shape of that compromise, even if it does not remove it entirely. It is not a small side project, either. AWS says it was written entirely by autonomous AI agents, built from the same API models that sit behind the AWS SDKs, and released under a public-domain dedication. That last part matters as much as the tool itself: this is AWS shipping a local stand-in for its own cloud, for free, with the gaps in public.

This article walks through what was actually announced, which services matter most in practice, how to install it on Linux, macOS and Windows, and where it still falls short. The short version is simple enough: if you write code that calls AWS, this is now the fastest honest way to test it. It is not a replacement for the real cloud, and AWS is fairly open about that.

What AWS actually announced

The announcement, on AWS What’s New on 11 November, is short and direct. “Starting today, you can use AWS Emulator to build and test AWS applications on your computer or in your continuous integration (CI) environment. Your existing AWS SDK and CLI calls go to AWS Emulator and come back in milliseconds, so you and your coding agents can find and fix errors locally, with no deployments or AWS account required.”

That last clause — “you and your coding agents” — is doing a lot of work. A human can wait a few minutes for a deployment. A coding agent cannot, at least not happily. Agents work in a loop: write, run, read the error, fix, repeat. Every round trip to the real cloud breaks that loop, costs money, and leaves resources behind if the agent forgets to clean up. A local emulator keeps the loop tight. The agent can create a DynamoDB table, test against it offline, and fix its code before it ever deploys, to use AWS’s own example.

There are three ideas in the announcement worth pulling apart. First, fidelity: for the operations it supports, the emulator returns the same result as AWS for valid calls, and the same errors for invalid ones. Operations it does not yet support return 501 Not Implemented, rather than a fake success. That is a deliberate choice, and a good one. A test that passes locally because the emulator invented a plausible answer is worse than a test that fails loudly.

Second, isolation. The emulator keeps the state of your resources in memory until you stop it. Each copy you start gets its own port, keys and in-memory state, so agents, test suites and CI jobs never see each other’s resources. Stop it, and the state is gone. That is convenient for tests, and it is also a limit, which we will come back to.

Third, coverage by generation. The services are generated from the API models AWS publishes, the same models behind the AWS SDKs. When AWS adds a service or API, it shows up in the emulator, and its behaviour is filled in and verified release by release. In other words, the emulator does not need a human to hand-write a new service from scratch. It starts from the model, then agents write tests against real AWS, find the gaps, and fix them. AWS publishes a fidelity report so you can see how its responses compare to AWS, service by service.

The part nobody wrote by hand

The strangest detail in this launch is also the most reported one: no human wrote or reviewed the code. Matthew Goldberg, a senior principal engineer at AWS, wrote in an About Amazon post on the same day that “the emulator was written entirely by autonomous agents. Our team hasn’t written or reviewed any of the code.” Thousands of autonomous agents wrote every line, he said.

It started, improbably, as a weekend experiment. Goldberg was inspired by Anthropic agents building a C compiler, and prompted the Kiro coding agent with three steps: write tests based on the CLI, iterate until they pass against real AWS, then build an in-memory implementation those tests pass against. Kiro returned a passable SQS emulator in about 15 minutes, then, in Goldberg’s telling, “the rest of AWS over the weekend” — with obvious gaps. The team started using it internally that Monday.

“All of AWS Emulator’s code was written and tested by agents, and it is built from more than 400 API models covering more than 200 AWS services. It runs free and offline on your own machine.”— Swaminathan Sivasubramanian, guest post on All Things Distributed, 11 November 2026

Behind that weekend demo, AWS built three agent teams running on Amazon Bedrock AgentCore. One team writes fidelity tests from the public API models and verifies each one against real AWS. A second team replays those tests against the emulator and files the failures into a public folder called things-that-do-not-work. A third team fixes them, one issue per agent, through a merge gate covering build, coding standards, security review and fidelity regression. Goldberg says thousands of issues are fixed every day, with hundreds of agents working on the codebase at once. Changes move through CodeCommit and CodePipeline before publication on GitHub.

Why release it under CC0, a public-domain dedication, rather than a normal open-source licence? Goldberg’s answer is that the full commit history and every issue are public, so the dedication matches the openness. The vendor code inside it is under Apache 2.0, and the repository does not accept pull requests — gaps are reported through GitHub Issues instead.

Which of the 200+ services matter most?

AWS says the emulator is built from 438 API models covering more than 200 services. That is a wide net, and it is wider than most free local AWS tools have managed. It is also not a promise that every service works equally well. There is no official ranked list of “most popular services”, and any article that invents per-service scores would be guessing. What AWS does publish is a fidelity score per service, per release, as a count of passing tests — for example, 40 of 50 fidelity tests pass — in each GitHub release. Those scores move as tests are added, so compare only scores from the same fidelity-test version.

The pattern AWS describes is clear enough. Control-plane APIs are strongest: create, describe, update, delete and list resources. Where implemented, invalid calls are rejected with the same errors as AWS. Data-plane APIs — the actual reading and writing of data, as opposed to creating the bucket or table — vary more by service, as do infrastructure-as-code tools such as CloudFormation, Terraform and the AWS CDK.

In practice, the services with direct evidence in AWS’s own material are the ones most developers will reach for first. Here is how they line up.

One service deserves a warning of its own: IAM. Do not present IAM as well supported. AWS says the emulator does not evaluate IAM or resource-based policies the way AWS does, so a request AWS would deny might succeed locally. That is not a small footnote. It means the emulator is for building and testing application logic, not for testing whether your application is secure.

How to install it

Installation depends on your operating system, and AWS is specific about it. On Linux, you install a package. On macOS and Windows, you run it in Docker. There is also an embedded mode, but only for Rust tests. There is no graphical interface and no console. It is a local HTTPS server, nothing more, and that is the point.

Linux: RPM or Debian package

The emulator installs to /opt/aws-emulator/ and adds aws-emulator to /usr/bin/. For x86_64 with DNF, for example on Amazon Linux 2023:

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

On Amazon Linux 2, use yum instead of dnf. For aarch64, use aws-emulator-aarch64.rpm. For Debian and Ubuntu, download the .deb first:

curl -fsSLo aws-emulator.deb https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest/aws-emulator_amd64.deb
sudo apt-get install -y ./aws-emulator.deb

Use aws-emulator_arm64.deb on Arm. If you want to verify the package, the signature is <package>.sig, the key is at https://downloads.aws.com/keys/gpg/current.asc, and the fingerprint should be 98BC F336 A3BE 53B7 34E9 67C5 2E5B F49B D940 F624 for [email protected].

macOS and Windows: Docker

AWS does not publish a ready-made Docker image. You build one from its Dockerfile, based on Amazon Linux 2023-minimal, which downloads the RPM and sets the entry point to aws-emulator -b 0.0.0.0. On Apple Silicon, use the aarch64 RPM instead. Then build and run it:

docker build -t aws-emulator .
mkdir -p ~/.aws/emulator
PORT=9297
docker run --rm --memory=2g --memory-swap=2g -p 127.0.0.1:$PORT:$PORT \
  -e HOME="$HOME" -v "$HOME/.aws/emulator:$HOME/.aws/emulator" \
  aws-emulator -p $PORT

Two details in that command matter. Use -p 127.0.0.1:9297:9297, not the short -p 9297:9297, or you expose the emulator to the whole network. And do not use -p 0 inside a container. The full Docker page in the AWS docs also has the Windows PowerShell equivalent, with the same port and volume mapping.

Embedded mode: Rust tests only

If you write Rust, you can also run the emulator in-process, inside your tests. Add it as a dev-dependency, pinned to a release commit rather than a tag:

aws-emulator-embedded = { git = "https://github.com/aws/aws-emulator", rev = "<commit>" }

Each test gets its own isolated in-process instance, with no endpoint URL, certificate or environment variables to manage. It works only with the AWS SDK for Rust. Building from source is heavier — Linux x86_64 or aarch64 only, Rust plus a C compiler, and AWS notes at least 100 GB of free disk for the build target directory — so most people should start with the package or Docker image.

How to use it locally

Start it, and it listens by default on HTTPS at https://127.0.0.1:9297, loopback only, with a self-signed certificate. On start it generates its own credentials, config and certificate in ~/.aws/emulator/9297/, in a subdirectory per port. The keys are regenerated on every start, access-key IDs start with EMULATOR, and requests signed with any other keys are rejected. Server mode requires SigV4 signing.

aws-emulator
# Ctrl+C or SIGTERM to stop — this deletes ~/.aws/emulator/<port>/ and all in-memory state
aws-emulator -p 9300   # a different port; -p 0 lets the OS pick a free port

Idle memory is about 160 MiB, and it grows with the resources you create. You can cap it with systemd if you want, for example systemd-run --user --scope -p MemoryMax=2G -p MemorySwapMax=0 aws-emulator. Check it is up with the health endpoint:

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

That should return HTTP 200 and ok. Then point the AWS CLI or SDK at it. The docs give a full set of environment variables, and they are worth copying exactly rather than improvising:

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
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE

Use 127.0.0.1, not localhost — some SDKs put the S3 bucket name in the hostname with localhost, and S3 Control requests do not reach the emulator. Windows PowerShell equivalents are on the same docs page. If you use an AI coding agent, AWS also has a skill for it, requiring AWS CLI v2.35.0 or later: aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1. The skill installs, starts and connects the emulator, and checks whether a project is expected to work against the fidelity tests and scores.

Once it is running, the first check is the identity call:

aws sts get-caller-identity

It should return the single emulator account, 000000000000, with the ARN arn:aws:iam::000000000000:user/emulator. Then try the two examples AWS uses in its News Blog. First, S3:

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/

Then DynamoDB, the example AWS shows via Kiro:

aws dynamodb create-table --table-name kiro-demo \
  --attribute-definitions AttributeName=id,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST
aws dynamodb put-item --table-name kiro-demo \
  --item '{"id": {"S": "item-1"}, "msg": {"S": "hello from kiro"}}'
aws dynamodb get-item --table-name kiro-demo --key '{"id": {"S": "item-1"}}'

If those work, your loop is set up. Write code, run it against the local endpoint, read the error, fix it, repeat. When you stop the emulator, the table and bucket disappear with it, which is exactly what you want for a test run, and exactly what you do not want for anything you need to keep.

One more default to know about: telemetry is on by default. AWS says it is anonymous and minimised, with no request or response contents, code, credentials or personal data, and it is not shared with third parties. You can turn it off with aws-emulator --telemetry off, with export EMULATOR_TELEMETRY=off, or in ~/.aws/emulator/config.toml under [telemetry] enabled = false.

What it does not do

The limits are not hidden, and they are worth stating plainly before you trust a local green test run too much.

• Unimplemented operations return 501 Not Implemented. That is the official AWS behaviour. Some secondary coverage says 503 instead — use 501, and treat the 503 figure as a conflicting secondary claim.
• One account, one Region. The single account is 000000000000, with no cross-account or cross-Region behaviour. Run one emulator per Region if you need to test several.
• In-memory only. State is lost when you stop it. There is no snapshot or restore, at least in the launch version.
• No throttling, outages or regional differences. That is the assessment of IDC analyst Devin Pratt, quoted in InfoWorld and GeekWire: the emulator does not yet simulate throttling, outages, or differences in which services and features are available by Region, and it does not sandbox the code it runs.
• Not for production or load testing. AWS says it is made for test runs, not for long-running use or load testing, and not for production workloads.
• No console. There is no GUI. If you want to see what is in there, you query it with the SDK or CLI.

None of that makes it useless. It makes it a test environment, not a cloud. The difference matters most when a test passes locally and you assume it will pass in production. Check the fidelity report for the operations you rely on, and run the real thing before you ship, especially for anything involving permissions, throttling or regional behaviour.

AWS Emulator vs LocalStack

The obvious comparison is LocalStack, the third-party emulator most developers already know. GeekWire puts it directly: LocalStack “this year put its free version behind an account requirement and limited it to noncommercial use. AWS released its emulator for free under CC0, with the full commit history on GitHub.”

The discussion online

The launch landed quickly. GeekWire’s Todd Bishop reported it on 11 November, starting from the weekend SQS experiment and the Kiro prompt that built it in 15 minutes. InfoWorld covered the same day, with the IDC view on throttling and outages. The Register followed on 12 November, with the headline that AWS had distilled its cloud into a local emulator that runs on a PC. On the AWS side, the All Things Distributed post and the About Amazon engineering account give the fuller story of how the agents were organised, and what Werner Vogels’ team plans to share at re:Invent.

If you want to follow the conversation, start with the official posts and the GitHub repository, then the coverage below. Hacker News carried the story on 11–12 November, with the points and comment count moving fast through the day, so any number quoted from there needs a date stamp. No exact X or LinkedIn post URL was verified for this article, so none is invented here — the official AWS posts and the repository are the reliable starting points.

• AWS News Blog — Test your applications against AWS locally with AWS Emulator
• All Things Distributed — AWS Emulator and the engineer’s job when agents write the code
• GeekWire — AWS gives developers a free local stand-in for its cloud, built from scratch by AI agents
• InfoWorld — AWS unveils local emulator service
• The Register — AWS distills its cloud into a local emulator that runs on your PC

What to try this week

1. Install it on your main machine — package on Linux, Docker on macOS or Windows — and run aws sts get-caller-identity.
2. Run the S3 and DynamoDB examples above, then stop the emulator and confirm the state is gone.
3. Point one small project at it with AWS_ENDPOINT_URL, and run its existing test suite locally.
4. Check the fidelity report for the services that project uses, before you trust a passing run.
5. When a call returns 501, check the GitHub Issues and the things-that-do-not-work folder — it may already be tracked, with a fix in progress.
6. Do not test IAM policies against it. Test those on AWS.

Sources & further reading

• AWS What’s New — AWS Emulator is now available for building and testing AWS applications locally, 11 Nov 2026
• AWS News Blog — Test your applications against AWS locally with AWS Emulator, 11 Nov 2026
• About Amazon — How autonomous AI agents built AWS Emulator, 11 Nov 2026
• All Things Distributed — AWS Emulator and the engineer’s job when agents write the code, 11 Nov 2026
• AWS Emulator documentation — Getting started · Fidelity report
• GitHub — aws/aws-emulator
• GeekWire, 11 Nov 2026 · InfoWorld, 11 Nov 2026 · Unite.AI · VandaTeam · Ministack