AWS Emulator runs AWS services locally, but it does not validate your IAM policies
On November 11, 2026 AWS made generally available a local emulator that answers the same APIs as the cloud, written in Rust and maintained by AI agents. Use it for your development loop, but draw no conclusions about the security of your IAM policies from it.
November 11, 2026. AWS makes AWS Emulator generally available, a local emulator of its services. 127.0.0.1:9297. That is the HTTPS endpoint where the AWS CLI, the SDKs, and your coding agents talk to it, using the same APIs they would use in production. Written in Rust. The binary sits on a laptop without weighing on the CPU. Why it matters: for the first time, a developer can run a real development loop against AWS — create a DynamoDB table, write an S3 object, read a queue — without deploying and without waiting on a round-trip to a Region, while keeping application code unchanged.
An emulator that speaks the cloud’s language
The principle is simple: install it, start it, then point your tools at the local endpoint. On startup, AWS Emulator generates its own credentials, a config file, and a certificate, written to ~/.aws/emulator/9297/. You then set environment variables so the SDK talks to your laptop instead of AWS.
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_REGION=us-east-1
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKENOnce the variables are set, your application code does not change. A unit test that creates a DynamoDB table, writes an item, and reads it back is the same test — but it runs on your machine, with no deployment. A coding agent can create a resource, check the result, and iterate again, without waiting for a deployment to propagate through a Region.
Two design details make the tool credible for daily use. First, the generated credentials carry the EMULATOR prefix, impossible to mistake for real keys, and the emulator rejects any request signed with any other key. Second, it requires SigV4 signing, exactly like AWS, and exposes a __admin/health endpoint so a script or container can wait until it is ready before running tests.
An embedded mode for parallel tests
Alongside the local-process mode, the emulator offers an embedded mode aimed at test suites. Instead of talking to a separate server, you instantiate the emulator directly inside the test process and wire it into the SDK through its HTTP client. Each instance keeps its own state — tests share no buckets, tables, or queues — and you can run many of them in parallel. Embedded mode is available for the AWS SDK for Rust, through the aws-emulator-embedded crate added to your dev-dependencies.
// Create a table, write, then read it back, entirely in-process
let emulator = AwsEmulatorEmbedded::new(EmbeddedOptions::default());
let config = aws_config::defaults(aws_config::BehaviorVersion::latest())
.http_client(emulator.http_client())
.region(aws_config::Region::new("us-east-1"))
.credentials_provider(emulator.aws_credentials_provider())
.load()
.await;For an engineer maintaining integration tests, that is the real win: tests that used to hit the real cloud become deterministic, fast, and free, without rewriting business code.
The fidelity question, taken head-on
An emulator is only useful if a test that passes against it would also pass against AWS. AWS addresses this with fidelity tests: short programs that run a workflow through an SDK — store an object, read it, delete it — and assert the expected behavior. Each test is verified against real AWS, and passes only if the emulator matches the cloud on every response: status code, body, exact error code and message, and the resources the workflow creates.
With each release, AWS publishes a per-service score in the form k of n — “40 of 50” means 40 of a service’s 50 fidelity tests pass. The test suite is public on GitHub, including the tests that still fail. A score reads as a snapshot of an improving product. When the emulator does not yet implement an operation, it returns HTTP 501 — the test fails immediately, with no false positive.
A tool maintained by AI agents
The most distinctive part is the production pipeline. AWS Emulator is built and maintained by agents from the AWS API models, using Amazon Bedrock AgentCore Runtime Instances, AWS CodePipeline, and AWS CodeCommit. One group of agents looks for gaps — comparing emulator responses against real AWS and statically comparing its code against the published Smithy models — and files an issue for each gap it finds. Another group picks up an issue, writes tests, implements the behavior, and reviews the change. The push triggers a pipeline that runs the fidelity tests before the change is published to the public repository.
Security follows the same principle: because agents write the code, an independent security agent reviews every change adversarially, during the work and again in the release pipeline as a final check before anything ships.
The limit that changes everything for an SRE
The most important passage in the announcement is a warning, not a feature. The emulator does not evaluate IAM policies or resource-based policies the way AWS does. Concretely, a request AWS would deny can succeed in the emulator. Each instance acts as a single account (000000000000), with no cross-account or cross-Region behavior.
The consequence is direct and worth stating plainly: do not use the emulator to test the security of your application. The measured fidelity covers the shape of the APIs, not the authorization control plane. A pipeline that “goes green” on the emulator can deploy a configuration AWS would reject — or worse, a configuration that passes on the emulator but behaves differently on AWS. Keep real credentials out of test environments, and validate security settings on AWS before production.
Verdict
If you develop against AWS or drive coding agents, adopt AWS Emulator for the local loop — resource creation, integration tests, agent iteration — it is a real win in speed and cost, and the public fidelity mechanism is honest. But if your goal is to validate IAM policies, service control policies, or security boundaries, stay on AWS: the emulator does not replace the authorization control plane, and using it as a security oracle would produce false confidence. For teams testing application behavior, the rule is simple: emulator for the logic, real cloud for the permissions.