Skip to content
audiotale.net
Sign in
NewsNews

AWS Emulator: free local AWS for tests, written by AI agents, CC0 licence

AWS's new free emulator answers the CLI and SDKs from your laptop. Here is how to set it up, what it skips (IAM) and why its per-service fidelity scores matter.

audiotale.net team

· 8 min read

Written by AI from the sources linked below. How we use AI

On this page
  1. Key points
  2. What to do
  3. What happened
  4. Background
  5. How it works
  6. What it means
  7. What we don't know yet
  8. What to watch next
  9. Sources

AWS has released AWS Emulator, a free program that answers the AWS CLI and SDKs from your own machine, so tests and coding agents can create buckets, tables and queues without touching an AWS account. It is generally available today, the source is public under a CC0 licence, and AWS says all of its code was written and tested by AI agents. For developers it also lands in a market where the best-known local AWS emulator, LocalStack, moved to account-based access this year.

Key points

  • AWS Emulator is generally available as of 11 November 2026, with no additional service fee; you pay only for AWS resources you deploy on AWS.
  • It serves the AWS APIs over HTTPS on 127.0.0.1:9297, installs from RPM or Debian packages on Linux, and runs in Docker on macOS and Windows.
  • AWS says it is built from more than 400 public API models covering more than 200 services, and that agents wrote and tested all of its code.
  • Fidelity is published per service as "k of n" passing tests; unimplemented operations return HTTP 501, and IAM policies are not evaluated.
  • The code is released under CC0, but the repository does not accept pull requests, and anonymous telemetry is on by default (it can be turned off).

What to do

If you test code that calls AWS, you can try it without changing application code. These steps come from the AWS launch post and the repository README:

  1. Install the aws-emulator package on Linux (RPM or Debian), or build the short Dockerfile from the documentation on macOS or Windows. AWS publishes no ready-made image.
  2. Run aws-emulator. On start it generates credentials, a config file and a certificate under ~/.aws/emulator/9297/.
  3. Point your tools at it with environment variables: AWS_ENDPOINT_URL=https://127.0.0.1:9297, plus the credentials and config files it wrote, and unset any real AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN and AWS_PROFILE.
  4. Check it is the emulator and not the real cloud: the health endpoint is /__admin/health, and the single emulated account is 000000000000. Its access key IDs start with EMULATOR, and it rejects requests signed with any other keys.
  5. Before relying on it, look up the fidelity score of each service you use on the releases page, and the README's issues/things-that-do-not-work/ folder for known gaps.
  6. If you do not want usage data sent, start it with aws-emulator --telemetry off, or set EMULATOR_TELEMETRY=off.

Some SDKs need an extra setting to trust the emulator's self-signed certificate; AWS gives the AWS SDK for Java's trust store as an example.

What happened

On 11 November AWS announced AWS Emulator on its News Blog. The emulator is a local program, written in Rust, that serves AWS API endpoints. The AWS CLI, the AWS SDKs and coding agents talk to it with the same API calls they would send to the cloud, and the application code stays unchanged. AWS's own example is a unit test that creates an Amazon DynamoDB table, writes an item and reads it back: the same test, run on a laptop with no deployment.

AWS says the emulator supports the APIs of services that have a model in its public AWS API models repository, and because it is built from the same models the SDKs use, requests and error responses have the same shape as on AWS. In an accompanying post, Swaminathan Sivasubramanian describes the scale: more than 400 API models covering more than 200 AWS services.

There are three ways to use it. As a local process it gives the CLI and any SDK an HTTPS endpoint, and every request must be signed with Signature Version 4, as on AWS. For Rust tests there is an embedded mode: you add the aws-emulator-embedded crate as a dev-dependency and wire the emulator's HTTP client into the SDK, so each test gets its own isolated instance and many can run in parallel. The README adds a warning about the cost: embedded mode compiles the emulator into your test binary, and the README says to budget at least 100 GB of free disk for target/, because the workspace has one crate per AWS service. A third route is a skill for AI coding agents, installed with the AWS CLI (version 2.35.0 or later, per the README).

The AWS post's author used Kiro, AWS's coding agent, to create a DynamoDB table, put an item and read it back against the local endpoint. AWS names Kiro and Claude Code as examples of agents that can use the emulator in their write, run and check loop.

Background

Local AWS emulation is an old need. Calling the real cloud from every test is slow and costs money, and an agent iterating on infrastructure code can make a lot of calls. For years the usual answer was LocalStack, an emulator that started as an open-source project. In its announcement, LocalStack said that from March 2026 LocalStack for AWS would be delivered as a single version that requires an account, and that free access would remain for students, hobbyists and open-source projects. InfoQ reported on 15 February that this dropped the Apache 2.0 Community Edition and that developers on Reddit were worried about it.

Other free projects have appeared since. Floci and fakecloud both have Hacker News threads with hundreds of points (292 and 154 at the time we checked), and we have not tested either. AWS's launch does not mention LocalStack, so any comparison is ours, not AWS's.

The idea behind AWS Emulator, according to Sivasubramanian, came from Matt Goldberg, a Senior Principal Engineer on the AWS Developer Tools team. His hypothesis: given a written description of how a service should behave and the real service to check against, an agent could build a working version on its own. The description is the Smithy API models; the real service is the AWS cloud. He began with Amazon SQS, and Sivasubramanian says that when Goldberg gave Kiro one prompt describing the approach, it returned a passable first SQS emulator in about 15 minutes.

How it works

The emulator is built around fidelity tests. A fidelity test is a short SDK program that runs a workflow, such as storing, reading and deleting an object, and asserts how AWS behaves. AWS verifies each test against real AWS first. A test passes against the emulator only if it matches AWS on every call: the status code, the body, the exact error code and message, and the resources the workflow creates.

With each release AWS publishes, per service, how many tests pass as "k of n"; for example, 40 of 50 means 40 of that service's 50 tests pass. The full set of tests is public in the aws-emulator-evaluation-suite repository, including those that fail today. AWS cautions that a score can fall when new tests are added even if the emulator improves. If an operation is not implemented, the emulator returns HTTP 501 so tests fail at once instead of passing falsely.

The build process is also agent-driven. According to AWS, one group of agents finds gaps, both by comparing emulator responses with real AWS and by statically comparing its code to the Smithy models, and files an issue for each. Another group picks up an issue, writes tests, implements the behaviour and reviews the change for correctness, performance and security. Each push triggers an AWS CodePipeline run of the fidelity tests before the change reaches the public repository, and an independent security agent reviews changes adversarially at two stages. Sivasubramanian says the repository's full commit history and every agent-filed issue are public.

What it means

For developers. Free local AWS testing from the vendor itself removes a reason to pay for or register with a third-party emulator, at least for services where the fidelity scores are high. The caveat is in the scores: coverage "varies by service and feature", AWS says, so a service you depend on may still return 501s. Check before you migrate a CI suite.

For security testing. AWS is direct that you should not use the emulator to test whether your application is secure. It does not evaluate IAM policies and resource-based policies as AWS does, so a request AWS would deny might succeed locally. It also models a single account with no cross-account or cross-Region behaviour. Keep real credentials out of the environment of test jobs.

For coding agents. Sivasubramanian argues the emulator gives agents a test environment inside their loop: write code, run it, read the result. In his post, an agent rebuilding a replication engine that took two engineers about four months the first time was supervised for four nights before he saw it had no way to check its results; once it had a spec and a test environment, the rebuild took about two hours. That is one anecdote from AWS's own engineers, not a benchmark, but it shows why AWS ships the emulator with an agent skill.

For open source. The code is under CC0, a public-domain dedication, except a vendor/ directory under Apache 2.0. But the README says the repository does not take pull requests. You can use, fork and embed it; contributions arrive as issues, and the agents decide what to implement.

What we don't know yet

  • How good the fidelity scores really are. AWS says they are published with each release, and we did not verify per-service numbers; read them before depending on a service.
  • Whether the "built entirely by agents" claim holds up under scrutiny. It comes from AWS and its engineers, and we found no independent review of the code.
  • How embedded mode's large build cost plays out in real CI, and whether SDKs beyond Rust get an embedded option. The launch post says embedded mode is available for the AWS SDK for Rust only.
  • What AWS will share at re:Invent. Sivasubramanian says there will be more on this work there.
  • What the usage telemetry covers beyond "anonymous usage and error data"; the documentation has a telemetry page.

What to watch next

Watch the releases page for the fidelity numbers by service, and the repository's things-that-do-not-work and things-that-now-work folders to see how fast agent-filed gaps close. Watch how LocalStack and the free alternatives respond, and whether the CC0 licence leads to forks or tools that bundle the emulator, a case the README already anticipates in its telemetry guidance. And watch re:Invent for AWS's fuller account of how the agents were organised.

Sources

SaveStart the discussion

Written by

audiotale.net team

The official account of the people who run audiotale.net: announcements, conversation starters and the newsroom's drafts. Posts written with AI say so. Every other account here is a real person.

Read next