A coding agent is only as good as the loop it can check its work in, and AWS Emulator, released by AWS on November 11, puts that loop on a laptop. If your team builds an AI product on AWS with Claude Code, Kiro or a similar agent, it can now create tables, queues and buckets and read them back without an AWS account or a deploy. This article covers what AWS shipped, the lesson AWS drew from building it, and the test setup we would put in place first, so an agent iterating at speed only ever talks to the emulator and never to your real account.

What AWS shipped

AWS Emulator is a local program that serves the AWS APIs over HTTPS. According to the AWS launch post, "The AWS Command Line Interface (AWS CLI), the AWS SDKs, and your coding agents speak to it over a local HTTPS endpoint using the same AWS APIs they would use in the cloud". You point your tools at it with environment variables (AWS_ENDPOINT_URL and a generated credentials file) and your application code stays the same. It runs from RPM or Debian packages on Linux and in Docker on macOS and Windows, with an embedded mode for Rust test suites, and it "has no additional service fee."

It was built and is maintained by agents. In a guest post on Werner Vogels' blog, Swami Sivasubramanian writes that "All of AWS Emulator’s code was written and tested by agents, and it is built from more than 400 API models covering more than 200 AWS services." Accuracy is measured with fidelity tests: short SDK workflows verified against real AWS, published per service as a pass count such as "40 of 50". An operation the emulator does not implement returns HTTP 501, so a test fails loudly instead of passing by accident.

The lesson is the loop

The most useful paragraph in the launch is about the engineer's job. Sivasubramanian describes rebuilding a replication engine he had first written over about four months: "I supervised the agent for four nights before I saw that 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 the general pattern with coding agents. An agent with no way to run what it wrote produces plausible code and leaves the checking to you. An agent that can create a DynamoDB table, write to it and read the result back corrects itself before you look. For a product on AWS, that environment was the hard part: a shared dev account is slow to deploy to, costs money, and is one wrong credential away from production. A local emulator removes most of that.

Fence the agent into the emulator

The risk moves to the edges. An agent running tests in a terminal inherits whatever is in that terminal's environment, and a developer machine usually has a real AWS profile on it. AWS's own post says to "Keep real credentials out of the environment of your test jobs". The emulator helps: per the launch post, its access key IDs start with EMULATOR and it rejects requests signed with any other keys. Nothing stops the reverse, though, a test that quietly signs with a real profile and calls real AWS.

A sketch of how we would close that gap, as a setup file that runs before every test (Vitest's setupFiles, or the equivalent in your runner):

// test/setup.ts: runs before every test file.
// A sketch: refuse to run unless AWS calls go to the emulator.
import { fromIni } from "@aws-sdk/credential-providers";

const endpoint = process.env.AWS_ENDPOINT_URL ?? "";
const local = /^https:\/\/127\.0\.0\.1:\d+$/.test(endpoint);

const leaked = [
  "AWS_ACCESS_KEY_ID",
  "AWS_SECRET_ACCESS_KEY",
  "AWS_SESSION_TOKEN",
  "AWS_PROFILE",
].filter((name) => process.env[name]);

const creds = await fromIni()();
const emulatorKey = creds.accessKeyId.startsWith("EMULATOR");

if (!local || leaked.length > 0 || !emulatorKey) {
  console.error("refusing to run against real AWS", {
    endpoint, leaked, emulatorKey,
  });
  process.exit(1);
}

Notice that it checks all three things an agent could get wrong: where requests go, whether real credentials are sitting in the environment, and whether the key it will actually sign with is an emulator key. If an agent "fixes" a failing test by exporting a real profile, the suite stops instead of running against your account. Put the same check in the agent's own instructions file so it knows why the suite refuses, and run the emulator in CI with no AWS credentials configured at all.

What the emulator can't tell you

AWS is direct about the limits. The emulator "doesn’t evaluate AWS Identity and Access Management (IAM) policies and resource-based policies the way AWS does, so a request that AWS denies might succeed in the emulator." Each instance is a single account with no cross-account or cross-Region behavior, and fidelity varies by service.

So keep two suites. The local one, which agents run on every change, covers behavior: does the code create, read and handle errors the way AWS would. A small second suite runs on a real sandbox account before release and covers what the emulator skips: least-privilege roles, bucket policies, cross-account access. Before moving a service's tests local, check its fidelity score in the documentation; a service at a low pass count will let tests pass that fail on AWS. If your product's risk sits mostly in permissions, the second suite is where most of your effort still goes. Our AI agent guardrails page covers the same scoped-key idea for agents in production.

What to take from it

  • Give a coding agent a spec and an environment to run against; Sivasubramanian's two-hour rebuild came from exactly that.
  • Point agent test runs at AWS Emulator, and make the test setup refuse to run if the endpoint, the environment or the signing key could reach real AWS.
  • Keep IAM and policy tests on a real sandbox account; the emulator does not evaluate them.
  • Check each service's fidelity score before trusting a local pass.

If your team is building an AI product on AWS with coding agents and wants the test loop and its guardrails set up properly, book a conversation.

Sources