AWS Emulator: Local Offline AWS for Coding Agents, Fidelity Tests, and Agent-Written Code

On November 11, 2026, Amazon Web Services released AWS Emulator: a local, offline emulator for AWS APIs that your coding agent can target instead of the live cloud. AWS senior principal engineer Matthew Goldberg says autonomous agents wrote every line—humans built the guardrails, not the implementation. In a guest post on Werner Vogels' blog, Swami Sivasubramanian frames the launch as putting infrastructure inside the agent loop the way Amazon once simulated distributed locks before shipping Alf. For anyone running Claude Code, Codex, Kiro, or similar tools against boto3 and Terraform, the product changes how agents validate cloud code—and the README security warning changes what you must not confuse it with.

TL;DR

What AWS announced

Three coordinated posts landed the same day:

1. How we built the agents that built AWS Emulator — Goldberg's technical narrative.
2. AWS Emulator and the engineer's job when agents write the code — Vogels introduces Swami's essay on distributed-systems testing and agent-written software.
3. How emulators might catch what you might miss — James Greenfield on why mocks miss service rules when agents write tests too.

Goldberg's origin story starts from Anthropic's agent-built C compiler demonstration: if agents can build from spec + reference, AWS already has Smithy models and the live cloud. His first Kiro prompt:

1. Write tests from the AWS CLI
2. Iterate until tests pass against real AWS
3. Build an in-memory implementation that passes the same tests offline

Kiro returned a rough Amazon SQS emulator in ~15 minutes; a weekend pass produced a gap-filled but usable multi-service build the internal team adopted Monday.

How the three agent teams work

Image: Amazon Web Services

Goldberg describes three bounded agent teams:

Team 1 — fidelity tests

Agents author end-to-end scenarios from public Smithy API models, verify each against real AWS, and commit tens of thousands of tests. Example SQS flow: create queue, send, receive, acknowledge, delete. Tests become a replayable oracle that does not require calling AWS again.

Team 2 — issue finders

Agents replay tests against the emulator, compare behavior, and file gaps under issues/things-that-do-not-work/. Fixed items move to issues/things-that-now-work/—a public honesty list on GitHub.

Team 3 — fixers

One agent per issue checks out code, patches until the issue passes, and submits through a merge gate. Goldberg says the gate blocks non-compiling changes, runs coding-standard agents, security adversarial reviewers, and fidelity regression checks. Failed checks return work to the agent; passes merge to mainline. AWS reports thousands of issues fixed per day with hundreds of concurrent agents.

Swami's Vogels post echoes the same structure: agents need coloring books—clear boundaries—not unconstrained autonomy.

Infrastructure inside the coding loop

The architectural point both posts stress: a coding agent loop is write → run → read output → revise. For cloud apps, "run" means calling AWS-shaped APIs. When those calls hit mocks the agent invented, tests pass for assumptions the agent already made. Greenfield's bartender game anecdote on dev.to is the concrete failure: the agent mocked SQS receipt_handle as an idempotency key, so a redelivered message after visibility timeout double-charged the customer. The test passed; AWS Emulator failed it because the emulator enforced new receipt handles per delivery, and the agent then fixed idempotency using order id.

That is the difference between mocking and emulation for agent workflows—and why AWS markets the tool to teams running multiple agents in parallel, each with its own emulator instance and no shared production account.

Repository facts developers should read

The aws/aws-emulator README (verified November 11, 2026) states:

• License: CC0 1.0 (public domain dedication), except vendor/ under Apache 2.0.
• No pull requests: report issues on GitHub; AWS agents maintain it.
• Endpoint: HTTPS on 127.0.0.1:9297 (self-signed cert) when built from source.
• Build cost: ~100 GB disk for a full debug build of every service crate—embedded mode compiles the emulator into your test binary.
• Security disclaimer: "Don't use it for production workloads or to test security."
• Telemetry: on by default; disable with aws-emulator --telemetry off, EMULATOR_TELEMETRY=off, or config—AWS says telemetry excludes request/response bodies and credentials.
• Agent setup skill: aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1 (requires AWS CLI 2.35.0+).

Goldberg notes amusing agent detours—such as agents building a custom Python interpreter for Lambda before humans steered them toward reusing libraries—under issues/ history. The repo shows tens of thousands of commits, consistent with agent velocity.

CC0 and maintenance expectations

AWS released the emulator under CC0 because, as press interviews summarized, the company did not want to assert copyright on code agents authored. Practically, that means you may fork, embed in CI images, or vendor the sources—but you should still read the Security section in the user guide and treat agent-maintained Rust like any other high-churn dependency: pin releases, watch things-that-do-not-work, and do not assume PRs will be accepted (the README states no contributions via pull request).

Ecosystem context

AWS's dev.to piece quotes LocalStack co-founder Waldemar Hummer welcoming shared fidelity work rather than competing only on breadth. Whether you standardize on AWS Emulator, LocalStack, Moto, or service-specific locals (SAM, DynamoDB Local), the agent-era lesson is the same: mocks travel with the agent's misconceptions; emulators enforce rules you did not think to encode. Pick tooling based on which services your agent touches and how much offline CI you need—not on launch headlines alone.

How Beam handles this (and what it does not)

AWS Emulator overlaps Beam only at the phrase "watch agents locally." Beam is not an AWS API emulator. It is local observability and heuristic policy on Claude Code, Codex, and related harnesses: PreToolUse denies on supported hooks, beam scan checks skills and MCP configs, and events are redacted before storage on your machine. AWS Emulator answers "does this boto3 call behave like AWS?" Beam answers "what did the agent try to run, and did it touch secrets or destructive commands?" Where they complement each other: run agent-generated integration tests against the emulator, and use Beam to flag when the same session runs aws CLI against production, edits .aws/credentials, or adds unpinned MCP launchers that pull code from PyPI mid-task—patterns we cover in Corelight's uvx MCP drift research. Beam does not validate Smithy fidelity or block 127.0.0.1:9297 traffic, and enforce policy is fail-open when cached workspace policy is missing.

What this means if you run AI coding agents

When to point agents at AWS Emulator

• Every CI run that previously needed a shared dev AWS account for integration tests.
• Parallel agent sessions implementing different features—Goldberg emphasizes isolated ports and state per instance.
• Catching service semantics mocks hide (SQS visibility, DynamoDB conditional writes, IAM implicit denies)—the dev.to post's core lesson.

What not to trust it for

• Penetration testing, secrets handling proofs, or IAM boundary validation—the README rejects those uses outright.
• Parity with production on day one: check release fidelity scores and issues/things-that-do-not-work/ before you gate merges on emulator-only tests.
• Supply-chain review of agent-written Rust: AWS trusts merge-gate security agents, not human line review—your org may still want dependency and SBOM policy on anything you ship to customers, separate from emulator tests.

Practical setup checks

1. Install or containerize per Quick start — Goldberg recommends asking your coding agent to install the aws-emulator skill.
2. Redirect SDK/CLI endpoints per README "Pointing your AWS SDK at AWS Emulator" (user guide linked from the repo).
3. Disable telemetry if your policy requires no usage reporting: export EMULATOR_TELEMETRY=off.
4. Keep production credentials out of the agent shell anyway—emulator isolation helps, but agents still read files; see Google Agent Compute Engine's credential-outside-sandbox pattern for the higher-isolation model.
5. Compare with existing local tools (DynamoDB Local, SAM CLI, LocalStack, Moto) when one service matters—AWS positions this as breadth + agent-maintained fidelity tests, not a drop-in for every niche emulator feature.

Engineer role shift

Vogels and Swami argue the human job moves to specs, tests, and gates:

• Fidelity tests verified against real AWS (Team 1)
• Merge gates with security agents (Team 3)
• Deterministic rules for what agents may edit (Swami lists guardrails that stop agents touching out-of-scope code)

That mirrors how we described OpenAI Codex Security separating offensive-shaped prompts from everyday coding—another gate, not unlimited agent autonomy. It also rhymes with Google Chrome Modern Web Guidance: agents need machine-readable constraints they can fetch and obey.

Swami's Alf anecdote on Vogels' blog is worth reading for the historical parallel: twenty years ago, Amazon simulated Paxos locking because chaos tests could not reproduce every ordering. Today, agents write code faster than humans can manually craft simulators per service. AWS Emulator is the bet that Smithy models + cloud truth + agent labor can keep a local twin close enough that the first integration test cycle catches semantic bugs—not the first customer invoice.

Relationship to Google's agent sandbox story

Beam's October write-up on Google Agent Compute Engine focused on microVM isolation and credentials injected only at an off-node gateway. AWS Emulator is the opposite emphasis: rich local API behavior without cloud spend, explicitly not claiming kernel-grade isolation. A mature setup might use emulators for fast correctness loops and stronger sandboxes (or separate accounts with session scopes) before agents touch production-shaped credentials—see also agent harness separation.

Frequently asked questions

What is AWS Emulator?

Per AWS, AWS Emulator is a local program that serves AWS API endpoints on your machine so CLI and SDK calls hit the emulator instead of the cloud. It requires no AWS account for emulation, ships as a Rust binary or container, and is released under CC0 on GitHub.

Did humans write AWS Emulator?

AWS says no human on the team wrote or reviewed the emulator code. Autonomous agents built it using Smithy API models as spec and real AWS as reference, with three agent teams for tests, issue finding, and fixes.

Is AWS Emulator safe for security testing?

The GitHub README explicitly says not to use it for production workloads or to test security. It is a functional fidelity tool for build and integration tests, not a hardened sandbox.

How do I point my SDK at AWS Emulator?

Start the emulator, then set environment variables so the AWS CLI or SDK uses the emulator endpoint. The README documents server mode on 127.0.0.1:9297 with a self-signed certificate and embedded mode for Rust tests. See the AWS Emulator user guide linked from the repository.

Does AWS Emulator send telemetry?

Telemetry is on by default per the README. AWS says records exclude request and response bodies, code, credentials, and personal data, and can be disabled with --telemetry off, EMULATOR_TELEMETRY=off, or config.

How does this compare to Beam for agent security?

AWS Emulator tests whether your app behaves like AWS locally. Beam is local observability and heuristic policy on coding agents—it does not emulate cloud APIs. Use both for different jobs: fidelity testing versus watching what agents do on your machine.

Related reading

• Google Agent Compute Engine: microVM per agent
• What are agent harnesses?
• OpenAI Codex Security CLI
• Chrome Modern Web Guidance for coding agents
• MCP uvx transitive dependency drift (Corelight)
• November 2026 attacks timeline
• Beam: how local watching works

Service counts, telemetry defaults, and merge-gate details reflect AWS posts and the aws/aws-emulator README as of November 11, 2026. Fidelity scores and issue folders change as agents commit—check the repository before you rely on emulator-only CI.