Amazon has released AWS Emulator, a local emulator of the AWS APIs that you run on your own machine, on a development server, or in continuous integration. You don’t need an AWS account, and there’s no extra service fee: you pay only when you later deploy to real AWS. Your CLI, SDKs, and coding agents talk to a local HTTPS endpoint with the same APIs they’d use in the cloud, and they work with emulated resources rather than real ones.
Amazon says every line of the emulator’s application code was written by autonomous AI agents running on Amazon Bedrock AgentCore, and that the team has not written or reviewed any of that code. Swami Sivasubramanian, head of AI services and data at AWS, writes that the emulator is built from more than 400 public API models covering more than 200 AWS services. Matthew Goldberg, a senior principal engineer on the AWS Developer Tools team, puts the figure at 438 models in his launch post. Source is on GitHub under CC0 1.0, except the vendor/ directory, which is under Apache License 2.0.
How we built the agents that built AWS Emulator
November 11, 2026
How you run it
On Linux you install an RPM or Debian package for x86_64 or aarch64 and start the aws-emulator command. On macOS and Windows you run it in Docker, from an image you build with AWS’s Dockerfile; AWS does not publish a ready-made container image. For tests written in Rust with the AWS SDK for Rust, there’s also an embedded mode: you add the aws-emulator-embedded crate, run the emulator in-process, and get isolated state per test, with no endpoint, certificate, or environment variables to set. Building from source is supported only on Linux, and AWS warns you’ll want at least 100 GB of free disk for target/.
In server mode the emulator serves HTTPS on 127.0.0.1:9297 with a self-signed certificate, and writes credentials, a config file, and that certificate to ~/.aws/emulator/9297/. Its access key IDs start with EMULATOR, and it rejects requests signed with any other keys. It uses a single account, 000000000000, and it requires Signature Version 4, the same signing scheme AWS uses. The official user guide has you point the AWS CLI or an SDK at it like this, then unset any real credential variables so your tools don’t sign with a live key:
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_PROFILEA health check at https://127.0.0.1:9297/__admin/health returns HTTP 200 and the body ok. To confirm your shell is talking to the emulator, not to AWS, you can run aws sts get-caller-identity. If you’ve reached the emulator, the account is 000000000000 and the ARN is arn:aws:iam::000000000000:user/emulator. If you see your own account ID, your requests are going to AWS.
Your application code doesn’t change. In the user guide, a bucket you create stays in the emulator until you stop it:
$ aws s3api create-bucket --bucket amzn-s3-demo-bucket
{
"Location": "/amzn-s3-demo-bucket"
}
$ aws s3api list-buckets --query 'Buckets[].Name'
[
"amzn-s3-demo-bucket"
]The same guide shows the emulator refusing a DynamoDB table name that’s too short, with the same validation error AWS returns. For coding agents, AWS ships an aws-emulator skill that installs, starts, and connects the emulator, and checks whether a project is expected to work on it. That needs AWS CLI 2.35.0 or later:
aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1The official AWS Developers account posted a short thread on the same path: the skill, one command to start it, and a separate instance for each agent or CI job, so they don’t share resources.
Build and test AWS applications on your own machine or in your CI pipelines, with no deployments and no AWS account. This is AWS Emulator, and it’s generally available today.
November 11, 2026
Brooke Jamieson, a senior developer advocate at AWS, posted a short walkthrough of getting started, with a link to the product page.
My favourite pre:Invent launch so far – AWS just launched an AWS emulator, and it’s built & maintained by thousands of AI agents! Get started at: https://t.co/FsU8SQZd6J
November 11, 2026
What it doesn’t do
AWS is clear that the emulator is for building and testing, not for production, and not for testing whether an application is secure. It doesn’t evaluate IAM policies or resource-based policies the way AWS does, so a request AWS would deny might succeed. You still need to test security settings, and the whole application, on real AWS before you go to production.
Each emulator is a single account and doesn’t keep resources separate by Region or account, even if a request names a different one. Some services share resources across all Regions on real AWS, and others don’t; the docs tell you to use one Region and one account for all requests to a given emulator, and to run a separate emulator on its own port if you need another Region. Fidelity checks are run against the US West (Oregon) Region, except for global services, which are checked in US East (N. Virginia). Differences in what a Region actually offers aren’t reflected.
Resources live in memory on your machine and disappear when the emulator stops. AWS hasn’t tested it for long-running use or load testing, and it recommends starting it for your tests and stopping it afterwards, or setting --idle-timeout. How closely it matches AWS varies by service and feature. Unimplemented operations return HTTP 501. Amazon S3 Control requests don’t reach it at all, because SDKs put the account ID in the host name and that can’t be turned off. Keep 127.0.0.1 in the endpoint URL too: if you use localhost, some SDKs put the bucket name in the host name, and the emulator doesn’t accept that form.
Telemetry is on by default. AWS says the records never include request or response contents, your code, your credentials, or personal data, and that they’re not shared with third parties. You can turn it off with aws-emulator --telemetry off, the EMULATOR_TELEMETRY=off environment variable, a [telemetry] enabled = false block in config.toml, or Telemetry::Off in embedded mode. If you ship a tool that includes the emulator, the README says you should tell users about telemetry and give them a way to turn it off.
How closely it matches AWS, in one release
Each GitHub release ships a scores.json.gz file of fidelity checks, and AWS says you should read a score as a snapshot: when new tests are added, a score can go down even if the emulator has improved. In the scores file published with release v1.0.322, 24,243 of 42,857 scored checks passed, or about 57%. Another 80 checks were marked skipped. Among checks that named a single service, about 90% passed for Amazon SQS, 79% for Amazon S3, and 77% for Amazon DynamoDB, while 46% passed for AWS Lambda and 16% for AWS CloudFormation. Individual gaps live in the repository under issues/things-that-do-not-work/, and fixed ones move to issues/things-that-now-work/. A separate evaluation suite is also on GitHub.
How the agents built it
| Team | What it does |
|---|---|
| Write and check tests against real AWS | Writes and grows fidelity tests from the public Smithy API models, and verifies each test against real AWS |
| Find where the emulator diverges | Replays those tests against the emulator and files grouped issues |
| Fix the issue, then pass the merge gate | Fixes one issue at a time; a change has to pass a merge gate or it’s sent back |
Goldberg’s About Amazon post traces the idea to a public demo of an autonomous C compiler from Anthropic. He prompted Kiro with a three-step plan and got a passable first Amazon SQS emulator in about 15 minutes, then had Kiro build “the rest of AWS” over a weekend, with gaps. The team started using that prototype the following Monday. Turning it into a product, he writes, took more than a weekend.
The agents now work in three teams. The first writes and grows a suite of fidelity tests from the public Smithy API models — the same models the official SDKs use — and verifies each test against real AWS. Goldberg says that suite now runs to tens of thousands of tests, and that those tests can be rerun later without calling AWS again. The second team replays the tests against the emulator, starting from what he describes as an empty web server that could accept requests for all 438 models but did nothing, and files grouped issues. The third team fixes one issue at a time. A change has to pass a merge gate that checks compilation, coding standards, security review, and that fidelity has not gone backwards, or it’s sent back for rework. Goldberg says hundreds of agents work concurrently, and that they fix thousands of issues every day. Independent security agents review changes adversarially during the fix and again in the release pipeline.
Marc Brooker, a distinguished engineer at AWS, says two things stand out. First, the emulator is built automatically, with no human in the loop — what he calls a real software factory. Second, it’s a component you can put in your own software factory. In the rest of his thread he notes that it supports more complete pre-integration testing, deterministic and non-deterministic simulation, and patterns such as LLM-guided fuzzing, without calling real AWS.
If you’re building with agents, or thinking about software factories, don’t miss this new post from Matthew Goldberg about the new AWS Emulator: https://t.co/uqYSGl30VN There are two very cool things here.
November 11, 2026
The agents’ primary repository is AWS CodeCommit, with the build running through CodePipeline and other AWS Developer Tools. Code is packaged as a downloadable binary, and only then published to GitHub. An earlier agent-built version invented its own Python interpreter for AWS Lambda; the team later told the agents to reuse existing libraries. The GitHub repository doesn’t take pull requests. Bugs and fidelity gaps go in GitHub Issues, and AWS says the most useful report names the service, the operation, your SDK and version, the request you sent, and how the response differed from real AWS.
In a guest post on Werner Vogels’ All Things Distributed, Sivasubramanian ties the launch to earlier work on testing distributed systems at Amazon, including a Paxos-based lock service known internally as Alf. He writes that he later used Kiro to rebuild Alf’s replication engine — work that had taken about four months the first time — and supervised the agent for four nights before realising it had no way to check its results. Once it had a specification and a test environment, the rebuild took about two hours. “When agents write the code and check their own work,” he writes, “the engineer’s job is to give them room to work on their own and to build the specs, tests, and merge gates that decide when that work is correct.” AWS says it will share more about this work at re:Invent.
Werner Vogels, Amazon’s CTO, posted the same point that runs through his introduction to the essay: you can only test a system properly in a high-fidelity copy of the environment it will run in.
In 2004, I picked @SwamiSivasubram as my intern. It was probably one of the best decisions I have made as Amazon’s CTO. He learned early that you can only test a system properly in a high-fidelity copy of the environment it will actually run in. AWS Emulator, launched today and written and tested entirely by agents, gives you that kind of environment for more than 200 AWS services.
November 11, 2026
AWS Emulator is available today. Here’s what I think this means for engineers today.
November 11, 2026
Clare Liguori, a senior principal engineer on AWS Agentic AI who works on Kiro, the Strands Agents SDK, and MCP, says building API emulators has been a large part of Amazon teams’ work this year, because it lets agents run against dependencies over and over in a local feedback loop. The most popular internal emulator, she writes, is the one that emulates AWS APIs: it’s 100% built by agents, and it’s now open source. In a related AWS Insights post, Dr Matt Wood argues that an emulator which evaluates requests against current state lets a coding agent catch a wrong assumption — such as how a worker should handle a duplicate order arriving from an Amazon SQS queue into Amazon DynamoDB — before it builds more code on top of that mistake.
AWS Emulator is here! Building API emulators has been huge for Amazon teams this year. We let agents run against dependencies over and over in a feedback loop, all in the local env. The most popular one internally emulates AWS APIs: it’s 100% built by agents and now open source.
November 11, 2026
Daniel Abib’s AWS News Blog post is the product announcement, with setup, embedded-mode examples, and the same limits. The user guide covers install paths, pointing an SDK at the emulator, fidelity, security, and telemetry. AWS says the emulator is updated many times a day as the agents keep adding tests and fixes.
Discover more from Sulat AI & Tech News
Subscribe to get the latest posts sent to your email.
