Takeaway: On November 11, 2026, AWS announced AWS Emulator, a local emulator for AWS APIs that you run on your own machine or in continuous integration. The AWS CLI, the AWS SDKs, and coding agents can point existing calls at a local HTTPS endpoint and get responses without a deployment or an AWS account. AWS says there is no additional service fee; you pay only for real AWS resources when you deploy on AWS. The source is on GitHub under the CC0 1.0 Universal public domain dedication. This is a local testing tool, not a Region of AWS, and it is not a security test harness. AWS is explicit that the emulator does not evaluate IAM and resource-based policies the way AWS does, that each instance behaves as a single account, and that you should not use it to decide whether an application is secure.
The intended loop is familiar: a test that creates a table, writes an item, and reads it back, or a coding agent that creates a resource, checks the result, and tries again, without waiting on a deployment in a Region. Daniel Abib’s AWS News Blog post names coding agents such as Kiro and Claude Code as a target audience. That is a different job from this week’s Gemini Decisions API, which scores closed-set questions. AWS Emulator is about pointing the same AWS APIs at localhost before you spend time or money in the cloud.
How you run it
AWS describes the emulator as a local program with no graphical interface. You install it, start it, and point your tools at the local endpoint. When it starts, it generates its own credentials, a config file, and a certificate, and writes them under ~/.aws/emulator/9297/. You set environment variables so the AWS SDK talks to your laptop instead of AWS. AWS says your application code stays unchanged. By default the process serves HTTPS on 127.0.0.1:9297, so only the same computer can reach it.
The News Blog’s walk-through sets AWS_ENDPOINT_URL to that address, points AWS_SHARED_CREDENTIALS_FILE and AWS_CONFIG_FILE at the generated files, sets AWS_EC2_METADATA_DISABLED and AWS_DISABLE_HOST_PREFIX_INJECTION to true, sets AWS_REGION and AWS_DEFAULT_REGION (the example uses us-east-1), and unsets AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, and AWS_PROFILE so a real profile cannot leak into the session. A /__admin/health endpoint on the same port lets a script wait until the emulator is ready. In the walk-through, that check and aws sts get-caller-identity confirm the shell is talking to the emulator, which uses a single account, 000000000000.
The emulator generates new keys each time it starts. Access key IDs start with EMULATOR, and the process rejects requests signed with any other keys. When it runs as a local process, every request must be signed with Signature Version 4. AWS also says that, by default, the emulator sends anonymous usage and error data, which you can turn off.
On Linux, AWS ships RPM and Debian packages for x86_64 and aarch64. The News Blog’s Amazon Linux 2023 example installs from https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest. On macOS and Windows, you build a Docker image from the Dockerfile in the documentation and run it in a container. AWS does not publish a ready-made image. You can also build from source. The emulator is implemented in Rust, which AWS presents as a way to keep CPU and memory use light on a laptop.
The What’s New post says the emulator keeps resource state in memory until you stop it, and that each copy you start gets its own port, keys, and in-memory state, so agents, test suites, and CI jobs do not see one another’s resources. Documentation adds that capacity depends on your machine, that the resources disappear when the process stops, and that AWS has not tested the emulator for long-running use or load testing. For tests written with the AWS SDK for Rust, you can also instantiate an embedded emulator inside the test process and wire it into the SDK through its HTTP client, via the aws-emulator-embedded crate. Each embedded instance keeps its own state. Other SDKs still use the local HTTPS endpoint; some need an extra setting to trust the emulator certificate.
Fidelity is a snapshot, not a blanket match
AWS says the emulator is built from the published AWS API models, the same models the AWS SDKs use, so requests and errors have the same shape as on AWS for the operations it implements. For those operations, AWS says 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 HTTP 501 Not Implemented, so a test fails immediately instead of silently drifting.
That is a design goal with a public yardstick, not a promise that every service is complete. AWS measures fidelity with short programs that use an AWS SDK to run a workflow and assert how AWS behaves, including status codes, bodies, exact error codes and messages, and the resources the workflow creates. AWS says it verifies each fidelity test against real AWS. With each release it publishes how many tests pass for each service, as k of n. The 40-of-50 figure in the documentation and the News Blog is an example of how to read a score, not a current total for a named service, and it is not a count of supported services. The tests are public in the aws-emulator-evaluation-suite repository, including ones that do not pass yet. Treat a score as a snapshot: when new tests are added, a score can go down even if the emulator has improved. Compare scores only when they use the same version of the tests.
Documentation says today’s match is closest for control-plane APIs that create, describe, update, and delete resources, while fidelity for data-plane APIs, and support for CloudFormation, Terraform, and the AWS CDK, varies by service. The What’s New post says AWS Emulator does not depend on an AWS Region, meaning you do not need an account or a Regional deployment to run it. That is not the same as modeling multi-Region behavior. The service documentation says the emulator accepts any Region and account ID in a request, but it does not keep resources separate by Region or account. Use one Region and one account for all requests to a given instance, or run a separate emulator on its own port. Fidelity tests are checked against AWS in us-west-2, except for global services, which are checked in us-east-1. Regional availability differences are not reflected.
Do not flatten the origin story into a support matrix. In an About Amazon post the same day, Matthew Goldberg, a senior principal engineer, wrote that when the system first created the repository it generated an empty web server that could handle requests for the 438 AWS API Models but did nothing. That is a statement about API models at the start of the project, not a claim that AWS Emulator supports 438 services today. Check the fidelity scores for the services you actually use.
Limits you should treat as hard, especially around security
The launch posts and the security documentation repeat a warning that is easy to skim past: do not use the emulator to test whether your application is secure. It does not evaluate IAM policies and resource-based policies the way AWS does, so a request that AWS would deny might succeed locally. The security guide is sharper still. Some services in the emulator evaluate IAM policies for IAM users and roles that you create in the emulator, but not the same way as AWS. The emulator never denies a request signed with its own key. It does not check AWS KMS key policies or Amazon S3 bucket policies, and it does not support calls across accounts or Regions. A request that AWS allows might also fail. Passing tests in the emulator does not show that your permissions are correct or safe.
Other limits are equally concrete. Each emulator acts as a single account; the getting-started identity is 000000000000, with no cross-account or cross-Region behavior. Keep real credentials out of the environment of your test jobs, and do not point the emulator at a real AWS profile. Use test data, not customer or production data. Test your security settings and the whole application on real AWS before you go to production. The default listener is only on 127.0.0.1:9297; documentation warns against opening the ports to the internet. If you start the emulator with authentication turned off, it serves any request, signed or not, which AWS says to use at your own risk. And when the emulator runs code for you, such as function code, documentation says that code is not isolated from your machine. If your question is whether an IAM policy or bucket policy will hold in production, the official answer is to ask AWS itself, not the process on localhost.
How AWS says the emulator is built
The News Blog states that AWS Emulator is built and maintained by agents from the AWS API models using Amazon Bedrock AgentCore Runtime Instances, AWS CodePipeline, and AWS CodeCommit, so it stays current as those models change. That is AWS’s description of its pipeline, not an independent review of the codebase.
Goldberg’s About Amazon post goes further, and should be read as a company account. He writes that thousands of autonomous AI agents wrote every line of code in AWS Emulator, and that the team has not written or reviewed any of the code. The claim is paired with guardrails: a merge gate that blocks changes that do not compile and includes agents that review coding standards, security, and fidelity; an independent security agent that, the News Blog says, reviews changes adversarially while a fix is being made and again in the release pipeline; and fidelity tests verified against real AWS. “Independent” here means a separate agent in AWS’s own workflow, not a third-party audit. Treat the “every line,” “no human review,” and security-agent language as AWS’s claim about how it built the product.
Goldberg describes three groups of agents: one manages a fidelity test suite, one finds divergences, and one fixes individual issues. He traces the project to a weekend experiment prompting Kiro to write CLI-based tests, iterate until they passed against real AWS, and then build an in-memory implementation, starting with Amazon SQS. He also writes that the team has seen thousands of issues fixed every day as hundreds of agents work on the codebase, and that there are tens of thousands of fidelity tests. Those figures are his. The public evaluation suite is the place to inspect the tests themselves. Code is published to GitHub at the end of the release process. The CC0 1.0 dedication makes that copy easy to inspect; it is not a substitute for reading the fidelity report before you trust a local test.
Availability at a glance
| Item | What AWS’s November 11 materials say |
|---|---|
| What launched | AWS Emulator, a local emulator for AWS APIs, generally available on November 11, 2026 |
| Cost | No additional service fee; you pay only for AWS resources when you deploy on AWS |
| Source and license | Published on GitHub under the CC0 1.0 Universal public domain dedication |
| How you talk to it | Point existing AWS SDK and CLI calls at a local HTTPS endpoint; application code is meant to stay unchanged |
| Default endpoint | HTTPS on 127.0.0.1:9297; health check at /__admin/health |
| Credentials | Generated per start; access key IDs begin with EMULATOR; other keys are rejected; SigV4 is required for the local process |
| Account model | Single account 000000000000; no cross-account or cross-Region behavior |
| State | In memory until the process stops; each instance has its own port, keys, and state |
| Install | RPM or Debian packages on Linux (x86_64 and aarch64); Docker on macOS and Windows, from an image you build (AWS does not publish a ready-made image); or build from source |
| Embedded mode | In-process mode for tests with the AWS SDK for Rust |
| Unimplemented operations | HTTP 501 Not Implemented |
| Fidelity | Public per-service scores, published as k of n with each release; treat scores as a snapshot |
| Security testing | Do not use it to test whether an application is secure; IAM and resource-based policies are not evaluated the way they are on AWS |
| How AWS says it is built | Agents using Amazon Bedrock AgentCore Runtime Instances, AWS CodePipeline, and AWS CodeCommit, plus merge-gate, security-agent, and fidelity-test guardrails (company claim, not an independent audit) |
FAQ
Is AWS Emulator a free local replacement for an AWS account?
It is a free local emulator in the sense that AWS charges no additional service fee and you do not need an AWS account to run tests against it. You still pay for real AWS resources when you deploy on AWS. It is not a Region, and it is not a complete copy of every AWS API. Unimplemented operations return HTTP 501, and fidelity varies by service.
How do I install it on Linux, macOS, or Windows?
On Linux, install the RPM or Debian package for x86_64 or aarch64 and run the aws-emulator command. On macOS and Windows, build a Docker image from the Dockerfile in the AWS documentation and run the emulator in a container; AWS does not publish a ready-made image. You can also build from source. After it starts, set the documented environment variables so the CLI or SDK talks to https://127.0.0.1:9297 and uses the generated emulator credentials, not a real AWS profile.
Does it support every AWS service?
AWS says the emulator supports the APIs of services that have an API model in the AWS API models repository, and that when AWS adds a service or API it shows up in the emulator, with behavior filled in and verified release by release. That is not the same as full support on day one. Check the published fidelity scores for the services you use. The “438 AWS API Models” figure in Goldberg’s origin story describes an empty server that could accept requests for those models and do nothing; it is not a count of supported services.
Can I use AWS Emulator to test IAM policies or application security?
No. AWS says you should not use the emulator to test whether your application is secure. It does not evaluate IAM policies and resource-based policies the way AWS does, so a request AWS would deny may succeed locally. The security documentation adds that the emulator never denies a request signed with its own key, and that it does not check KMS key policies or S3 bucket policies. Test security settings and the full application on real AWS before production, and keep real credentials out of test jobs.
What do the fidelity scores mean?
For each service, AWS publishes how many public fidelity tests the emulator passes, as k of n, with each release. A test passes only if the emulator matches AWS on every call in the workflow, including errors and resulting state. Read the score as a snapshot. When AWS adds tests, a score can fall even if the product has improved. The tests, including ones that do not pass yet, are in the aws-emulator-evaluation-suite repository.
What happens if an API is not implemented yet?
The emulator returns HTTP 501 Not Implemented, so the calling test fails right away instead of returning a made-up success. AWS invites reports of differences through issues on the AWS Emulator GitHub repository.
Is the “written entirely by autonomous agents” claim an independent audit?
No. Goldberg writes that thousands of autonomous AI agents wrote every line and that the team has not written or reviewed the code, and AWS describes merge-gate, security-agent, and fidelity-test guardrails, including a security agent that reviews changes adversarially. Those are Amazon and AWS statements about their own process. They are not a third-party audit of the repository.
Does embedded mode work with every AWS SDK?
AWS documents embedded, in-process mode for the AWS SDK for Rust, via the aws-emulator-embedded crate. Other SDKs and the AWS CLI use the local HTTPS endpoint and environment variables. Some SDKs need an extra setting to trust the emulator certificate.