AWS Emulator for AI Coding Agents: Setup and Testing Limits

AWS Emulator, released on November 11, lets developers and AI coding agents test AWS applications locally without provisioning the corresponding cloud resources. It has no additional service fee. The important limit is security: a successful local test does not establish that your IAM permissions work correctly on AWS.

That distinction should shape how you adopt it. A coding agent needs quick feedback about whether its code behaves as intended, but it also needs to know which conclusions a test cannot support. Treating every green test as deployment approval would throw away much of the value of adding a better test environment.

What AWS Emulator runs and what it costs

The AWS launch announcement describes a local HTTPS endpoint that the AWS CLI, SDKs and coding agents can use. Linux has RPM and Debian packages; macOS and Windows use Docker. You still pay for actual AWS resources when you deploy to AWS.

According to the official repository, an AWS account is not needed for the emulator itself. There is no graphical interface. Server mode connects through an endpoint; embedded mode runs inside Rust tests. Building from source is substantially heavier than installing a package: the README calls for at least 100 GB of free space for the build directory.

There is also telemetry enabled by default. The README documents aws-emulator --telemetry off for disabling it for a process. Local execution and telemetry settings are separate questions, so review both when adding this to a development environment.

Set up the coding-agent skill first

AWS’s agent setup guide requires AWS CLI version 2.35.0 or later. Its documented installation command is:

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

The command installs the skill for coding agents the CLI finds, including examples such as Kiro, Cursor and Claude Code. The skill can help install the emulator, configure the client and diagnose connection or signing problems. This is a documentation-based setup guide, not a report of a local installation or benchmark.

Give the agent a narrower first job than migrating your entire test suite. A useful prompt is: “Identify the AWS operations this repository uses, check their emulator fidelity coverage, and propose one local integration test. Keep production credentials and customer data out of the test environment. Explain what must still be tested against real AWS.”

That prompt asks for an adoption decision before a large configuration change. It also makes the missing coverage visible instead of allowing a working happy-path demo to stand in for compatibility.

Confirm the tests are reaching the local endpoint

After the emulator is installed and running, AWS’s SDK configuration guide gives these shell settings for the default port:

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_EC2_METADATA_DISABLED=true
export AWS_DISABLE_HOST_PREFIX_INJECTION=true
export AWS_REGION=us-east-1
export AWS_DEFAULT_REGION=us-east-1
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE
aws sts get-caller-identity

The documented emulator account is 000000000000. If the identity command returns your real account, stop: the shell is reaching AWS. Keep these settings in the same isolated script or shell that runs the tests, rather than adding them indiscriminately to your normal cloud environment.

The example targets the CLI and clients that honor these settings. Some SDKs need additional certificate or host-prefix configuration; use the language-specific table in the guide. Keep 127.0.0.1 rather than casually substituting localhost, because SDK hostname handling can change where requests go.

A useful first workflow: queue message to database record

Consider an application that reads an order from SQS and stores a record in DynamoDB. A proposed local test can seed a synthetic message, run the consumer and assert that the expected record exists. Add a second case for malformed input and a third for repeated delivery if your application promises idempotent processing.

The important assertions belong to your application. “The SDK call did not throw an exception” is weaker than checking the record’s identifier, amount and processing state. Ask the agent to explain why each assertion would catch a plausible implementation mistake.

Before trusting this test, map its operations to the emulator’s fidelity tests and the scores for the release you use. AWS documents that uncovered behavior may work, but is not confirmed by its fidelity suite. A service name appearing in a supported API model is not enough evidence for every workflow built on that service.

For missing coverage, compare the same synthetic scenario against a controlled AWS test environment. Keep that comparison separate from the fast local loop so you can see whether a failure comes from application logic or an emulation difference. These are suggested test cases, not results obtained for this article.

What the emulator cannot prove

AWS’s security guide explicitly rules out using the emulator to validate IAM policies, permissions boundaries, resource policies, KMS key policies or cross-account and cross-Region access. Some IAM behavior exists, but it does not match real AWS enforcement.

A request that succeeds locally can still be denied in AWS. Keep permission tests and final application validation in a real AWS environment. Otherwise, an agent can “fix” an authorization problem by satisfying an emulator that never exercised the relevant restriction.

Keep the emulator private, use synthetic data and exclude real credentials. AWS also warns that code the emulator runs, such as function code, is not isolated from your machine and runs with your user’s permissions. An emulator is not automatically a sandbox for untrusted agent-generated code.

The useful change is a cheaper place to catch ordinary application mistakes before cloud testing. Give the agent that faster feedback loop, but make the boundary explicit: local behavior checks first, cloud fidelity and security checks before release.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain developer tools and engineering decisions through clear, useful technical stories.

Book a 30-minute call