The cloud, running on one laptop.
By Ellis Ward | November 12, 2026
AWS shipped a free local stand-in for its cloud services on Wednesday. The company attached a claim that developers rarely see from enterprise software teams: not a single human wrote or reviewed the code.
The tool, called AWS Emulator, lets developers run AWS services on their own machines without network access or cloud charges. It covers more than 200 services, built from more than 400 API models. Written in Rust, it runs as a local HTTP server on Linux, macOS, and Windows. AWS released it under the CC0 public domain dedication, with the full commit history available on GitHub.
A Weekend Experiment That Shipped
The project did not start with a roadmap. An engineer prompted Kiro, AWS's coding agent, to build Amazon SQS. The agent completed the task in 15 minutes. That result was enough to push the experiment further.
Matt Goldberg, a Senior Principal Engineer at AWS, described how the system now sustains itself. Autonomous agents handle ongoing maintenance, drawing from public API models and checking their output against real AWS behavior. The agents run on Amazon Bedrock AgentCore and operate in three distinct teams, each responsible for different parts of the codebase.
Goldberg's account, published on All Things Distributed, frames the project as a question about what engineers do when agents write the code. AWS found that engineers set direction, review work at a systems level, and handle the gaps that agents cannot resolve on their own. The line-by-line authorship is gone. The architectural judgment is not.
What Developers Get
For teams running integration tests or working in environments without reliable internet, the emulator offers a local alternative to provisioning real AWS resources. Spinning up a test queue or bucket no longer requires a live account or a network call. The tool handles the API surface directly on the developer's machine.
The 400-plus API models give the emulator broad coverage, though breadth and fidelity are different things. The emulator does not yet simulate throttling, service outages, or regional differences. Those behaviors are common sources of production bugs. Developers who test only against the emulator may not catch failures that depend on them.
AWS tracks the gaps publicly. A folder in the GitHub repository, labeled "things-that-do-not-work," holds a running backlog of known limitations. The name signals a team comfortable with transparency about what the tool cannot do yet.
Sandboxing Is an Open Question
The emulator does not sandbox the code it runs. That matters for teams that treat local test environments as isolated from broader systems. Developers should factor that in before integrating the emulator into automated pipelines that carry broad system access.
What the Analysts Say
Devin Pratt, an analyst at IDC, spoke to InfoWorld about the tool's current limits. Pratt pointed to the missing simulation of throttling, outages, and regional differences as meaningful gaps for teams trying to build resilient systems. The public list of known gaps is a useful signal, but it also tells you how much surface area remains unfinished.
The throttling gap is worth dwelling on. AWS rate limits are a frequent production headache. A local emulator that never throttles will not surface the kind of backoff logic failures that appear only under real traffic. Teams relying on the emulator for full-stack confidence will need to supplement it with live testing against actual AWS endpoints.
Competitor Context: LocalStack Changes the Field
AWS released the emulator into a market with an established leader. LocalStack has been the default for developers wanting a local AWS environment. This year, LocalStack moved its free tier behind an account requirement and restricted it to noncommercial use.
That move changed the calculus for open-source projects and individual developers. AWS Emulator arrives as a CC0-licensed alternative with no account requirement and no use restriction. The timing is not subtle.
LocalStack still carries years of maturity and community investment. AWS Emulator is a newer entrant with broader service-coverage claims and an unusual provenance. How the competition plays out will depend partly on which gaps the agents close first, and how quickly.
Agents Maintaining the Tools Agents Built
There is a recursive quality to this release. Amazon Bedrock AgentCore, the platform the emulator's agents run on, is an AWS product. The agents maintaining the emulator check their output against real AWS, which means the tool depends on the infrastructure it is meant to replace during local development.
That circularity is not a flaw. It is how the accuracy mechanism works. Agents check their own output against the source of truth, then update. The feedback loop does not require human review at each step, which is exactly the claim AWS is making about how the codebase came to exist.
Goldberg's post on All Things Distributed frames the shift carefully. He does not argue that engineers have become optional. He argues the job is changing: more direction, more architectural judgment, less line-by-line authorship.
What Comes Next
AWS said it will share more about the emulator at re:Invent. The conference is where the company typically expands on early releases and signals roadmap direction. The public backlog on GitHub offers a preview of where the agents will focus between now and then.
For developers tracking agent tooling, this release is a data point, not a verdict. The claim that no human wrote or reviewed the code is verifiable: the commit history is public on GitHub. What it means for the broader trajectory of software development is a question re:Invent may only partially answer.
