AWS Emulator Explained: What It Is, How It Works, Limits and Risks

Last updated: 13 November 2026

On 11 November 2026, Amazon Web Services released AWS Emulator, a free program that imitates the AWS cloud on your own computer. You point the AWS CLI or an SDK at it, and instead of creating real queues, buckets and tables in a paid account, everything happens locally and offline. Developers have wanted an official tool like this for years, so the launch alone would have been news.

What made it the most discussed developer story of the week is how it was built. AWS says the emulator was “100% written by autonomous AI agents”, with hundreds of agents writing tests, finding bugs and fixing them in parallel, and with the full commit history and issue list made public. Within two days the Hacker News thread about it had passed 950 points and 260 comments, with excitement and scepticism in roughly equal measure.

In this post I explain what AWS Emulator is, how the agent-built pipeline works, how to try it using the official method, what the early fidelity numbers really say, the limits and security caveats, and why I think every Indian student learning cloud, DevOps or software testing should pay attention, both to the tool and to the way it was made.

Quick summary

• What it is: A local emulator of the AWS APIs. Your code talks to it exactly as it would talk to AWS, but nothing leaves your machine.
• Who made it: AWS, announced on 11 November 2026 in a post by Senior Principal Engineer Matthew Goldberg and a guest post by Swami Sivasubramanian on Werner Vogels’ blog.
• Coverage: Built from 438 AWS API models according to the official post; AWS’s blog post describes this as “more than 200 AWS services”.
• How it was built: Teams of AI agents write fidelity tests against real AWS, find failures and fix them, behind an automated merge gate.
• Cost and licence: No service fee and no AWS account needed for local testing. The code is CC0 (public domain dedication), except a vendor/ folder under Apache 2.0.
• Reality check: Fidelity varies a lot by service, IAM permissions are not enforced the way AWS enforces them, and AWS itself says not to use it for production or for security testing.

What is AWS Emulator, in plain language?

Cloud applications are awkward to test. If your program sends messages to Amazon SQS, stores files in S3 and writes to DynamoDB, a realistic test normally needs a real AWS account. That means credentials, network access, waiting for resources to be created, cleaning them up afterwards and, for a student, the constant worry of a surprise bill.

An emulator removes that dependency. It is a program that listens on your machine and answers AWS API calls the way AWS would: create a queue, and it remembers the queue; send a message, and you can receive it; ask for something that does not exist, and you get the same kind of error AWS would return. Your application cannot tell the difference, as long as the emulator’s behaviour is faithful.

Third-party tools such as LocalStack and the Python library moto have offered this for years. AWS Emulator is different in two ways: it comes from AWS itself, and its stated goal is to cover the full breadth of AWS APIs rather than a popular subset. According to independent coverage by Cloud Computing News and the project’s own code, it is written in Rust, with one crate (Rust package) per AWS service.

How it was built: an AI agent factory

The build story is the reason this release matters beyond cloud developers.

According to Goldberg’s post, the experiment started with a single, very simple prompt to Kiro, AWS’s AI coding tool. About 15 minutes later it returned a rough but working emulator for Amazon SQS. An internal version came together over a weekend, and Sivasubramanian writes that it started gaining adoption inside AWS within a month. Turning that prototype into a product took a much larger system.

The key idea is that AWS already had two things most software projects lack: a complete machine-readable specification (the API models that AWS SDKs are generated from) and a perfect reference implementation (real AWS). The repository began as an empty web server that accepted requests for all 438 API models but did nothing. Then three teams of agents took over:

1. Test writers create fidelity tests from the API models. Each test is a short, real-world scenario, for example create a queue, send a message, receive it, acknowledge it and delete the queue. Every test is checked against real AWS before it is accepted. The evaluation suite says each was verified against at least two sandboxed AWS accounts.
2. Issue finders replay those tests against the emulator and file an issue whenever the emulator behaves differently from AWS.
3. Fixers each take one issue and propose a change. The change must pass a merge gate of build checks, code review, security review (including adversarial security agents, according to Sivasubramanian) and a fidelity check that the change did not make anything worse.

AWS says hundreds of agents work on the codebase concurrently and thousands of issues are fixed every day. (The summary line of the official post mentions thousands of agents, while its body says hundreds work at the same time; the larger figure seems to match issues fixed per day rather than agents running at once.) The tests now number in the tens of thousands, and when I checked, the public GitHub repository showed 29,684 commits.

Neither AWS post names the underlying language models. Goldberg names Kiro and AWS developer tools such as CodeCommit; Cloud Computing News also mentions Amazon Bedrock AgentCore, which I could not confirm in the official post. Goldberg credits Anthropic’s earlier experiment, in which agents wrote a C compiler, as inspiration for the “spec plus reference implementation” approach. He also shares a revealing failure: an early version of the agents tried to write their own Python interpreter to run Lambda functions, until AWS told them to reuse existing libraries. Agents left alone will happily rebuild the world.

What it can do

A small example of what “fidelity” means: Sivasubramanian points out that in SQS a received message must stay hidden from other readers until its visibility timeout expires. A naive emulator might just hand the same message to every reader. Tests like this are exactly what the agent pipeline checks.

How to try it (official method)

There are three supported routes, all described in the official GitHub README.

1. Let your AI coding agent set it up. With AWS CLI 2.35.0 or later, add the skill and then ask your agent to install and configure the emulator:

aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1

2. Run it as a server. On Linux, install the RPM or Debian package from the releases page and run:

aws-emulator

On macOS and Windows, the README says to run it in a container built from a short Dockerfile in the repository. I could not find an official prebuilt image name, so be careful with any image on Docker Hub claiming to be “the” AWS Emulator.

3. Point your tools at it. The AWS user guide gives the exact environment variables. On Linux or macOS the core ones are:

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_REGION=us-east-1
export AWS_DEFAULT_REGION=us-east-1

# Make sure real credentials are not used by mistake
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE

# Should report account 000000000000, not your real account
aws sts get-caller-identity

The guide lists two more variables (AWS_EC2_METADATA_DISABLED and AWS_DISABLE_HOST_PREFIX_INJECTION) and per-language certificate settings for Node.js, Java, Rust and .NET, so follow it exactly for your SDK. The get-caller-identity check is the habit I would teach every student: always confirm you are talking to the emulator before running anything destructive.

Building from source is possible on Linux, but the README asks for at least 100 GB of free disk for build output, so most students should use the packages.

Limits, criticism and early test results

The honest picture is more mixed than the headlines.

• Fidelity varies widely by service. AWS publishes a scores file with each release but, as far as I could find, no headline summary. A Hacker News commenter analysed that file and posted unofficial per-service pass rates, for example around 69% for DynamoDB, 68% for SQS, 62% for S3, 53% for Lambda, 40% for EC2 and 36% for CloudFormation. These are one user’s numbers from one release, not AWS figures, but they match the general message: core services are usable, many others are partial.
• Untested means unverified. The evaluation suite states plainly that behaviour not covered by a fidelity test is not verified. Coverage is strongest for control-plane operations (creating and configuring resources); data-plane behaviour and infrastructure-as-code tools like CloudFormation, Terraform and CDK vary by service.
• IAM is not enforced like AWS. A request that AWS would reject for missing permissions might succeed locally. Your tests can pass while your real deployment fails.
• No failure simulation yet. Analysts quoted by InfoWorld (via Cloud Computing News) note the first release does not simulate throttling, outages or regional differences, and that timeouts and partial failures still need testing on real AWS.
• Single account, single Region. Cross-account and cross-Region behaviour is out of scope, and the docs note that S3 Control requests do not reach the emulator.
• Maintenance questions. The repository does not accept pull requests (issues are welcome), and the test repository is maintained by agents. On Hacker News some developers asked whether this is a real product or an experiment, and whether roughly a thousand commits a day signals maturity or churn. An AWS engineer replied: “It’s a real product that we plan to maintain.” AWS says it will share more at re:Invent.

On the positive side, many developers simply welcomed a first-party option. Advait Patel of Broadcom, quoted in Cloud Computing News, summed up the practical upside: “Teams get faster feedback, fewer leftover test resources, and smaller dev account bills.” My own view is that the tool will be most useful for fast unit and integration tests of common services, with a smaller set of tests still run against a real sandbox account before release.

Security and privacy: what to watch

• Not a security testing tool. The README is explicit: “Don’t use it for production workloads or to test security.” Since IAM is not evaluated like AWS, a passing local test says nothing about whether your permissions are correct.
• Code is not sandboxed. According to AWS documentation cited by Cloud Computing News, code the emulator runs (for example a Lambda function) executes with your own user permissions and can read or change local files. Run only code you trust.
• Local only by default. It listens on 127.0.0.1. Do not expose it on a shared network, and read the security page before using the --auth off option.
• Telemetry is on by default. You can turn it off with aws-emulator --telemetry off, the environment variable EMULATOR_TELEMETRY=off, or the config file. Colleges deploying it in labs should decide this up front.
• Keep real data out. Use synthetic data in tests. If you are building apps for Indian users, remember that personal data handling falls under the Digital Personal Data Protection Act, 2023, and copying real customer data into developer laptops is poor practice regardless of the tool. (This is general information, not legal advice.)

Why this matters for Indian students and educators

For students, the most immediate benefit is practical. AWS sign-up normally asks for a payment card, and many of my students have either avoided cloud practice or been scared by an unexpected bill after forgetting to delete a resource. A free, offline emulator lets you practise SQS, S3, DynamoDB and Lambda workflows on a laptop, in a college lab without reliable internet, or inside a CI pipeline for a project, with no account at all. It is not a replacement for real AWS experience, but it lowers the entry barrier a lot.

It also maps neatly onto the syllabus:

• Computer Networks: HTTPS, TLS certificates, why a self-signed CA bundle is needed, and request signing.
• Operating Systems: processes, ports, file permissions and why “not sandboxed” matters.
• DBMS: key-value stores like DynamoDB versus relational databases, and consistency behaviour.
• Distributed systems: message queues, visibility timeouts and at-least-once delivery, all of which you can now experiment with safely.
• Software Engineering and testing: unit versus integration tests, test doubles, CI, and the idea of a “reference implementation”.

The bigger lesson is about how AI is changing software work. Notice what made the agent factory succeed: not a clever prompt, but a precise specification, a trustworthy reference to test against, and a strict merge gate. Sivasubramanian makes a similar point from his own experiment, where an agent struggled for days until it had a spec and a test environment. For students preparing for GATE CSE or GATE DA, or for careers as cloud engineers, DevOps engineers and SDETs, the skills that rise in value are writing specifications, designing tests and judging whether evidence is trustworthy. Those are exactly the fundamentals our syllabi already teach; AI makes them more important, not less.

For educators, this is a ready-made case study. Ask students to read a few agent-filed issues in the public repository, pick a fidelity test, run it against the emulator, and explain why it passes or fails.

Frequently asked questions

Is AWS Emulator free?

Yes. AWS says there is no additional service fee and no AWS account is required for local testing. You pay only if you deploy to real AWS.

Is AWS Emulator open source?

The code is released under CC0, a public domain dedication, apart from a vendor/ directory under Apache 2.0. The repository accepts bug reports as issues but not pull requests.

Was it really written entirely by AI?

That is AWS’s claim: the code was written by autonomous agents, with humans designing the system, the tests’ acceptance rules and the merge gate. The full commit history and the agents’ issues are public, so anyone can inspect the work.

How is it different from LocalStack or moto?

LocalStack and moto are long-standing third-party tools. AWS Emulator is first-party, aims to cover all AWS API models, and measures itself with published fidelity tests verified against real AWS. Maturity per service differs, so compare the services you actually use before switching.

Can I use it to learn for AWS certifications?

It is useful for practising API workflows with the CLI and SDKs. It does not include the AWS Management Console, and IAM behaviour differs, so it cannot replace hands-on practice in a real account for console and security topics.

Will my tests that pass locally always work on AWS?

No. Permissions, throttling, failures and untested behaviour can differ. Keep a smaller set of tests that run against a real sandbox account.

The bottom line

AWS Emulator is two stories in one. The first is a useful, free tool that makes cloud development and learning cheaper and faster, especially for students who have avoided AWS because of cost. The second is a public, large-scale example of AI agents building and maintaining a real product, driven by specifications and tests rather than human-written code. Both stories come with the same caveat: the emulator is only as trustworthy as its tests, and today those tests cover some services far better than others. Use it, learn from it, and keep checking against the real thing.

Sources and further reading

• Amazon: AWS Emulator, a local emulator built 100% by autonomous AI agents (Matthew Goldberg)
• All Things Distributed: AWS Emulator and the engineer’s job when agents write the code (Swami Sivasubramanian)
• GitHub: aws/aws-emulator (official repository and README)
• GitHub: aws/aws-emulator-evaluation-suite (fidelity tests)
• AWS user guide: pointing your AWS SDK at AWS Emulator
• SD Times: Amazon releases AWS Emulator to allow its services to run locally
• Cloud Computing News: AWS launches cloud emulator built entirely by AI agents
• Developers Digest: AWS Emulator review and Hacker News reaction
• Hacker News discussion: AWS emulator

Written by Piyush Wairale (M.Tech, IIT Madras), founder of PiyushAI Edtech. Commit counts, fidelity scores and discussion figures change daily; figures are as reported on or before 13 November 2026.