AWS Shipped a Free Local Emulator That AI Agents Keep Up to Date. Telemetry Is On by Default and IAM Is Not Checked. Here Is How I'd Use It.
AWS put a repo called aws/aws-emulator on GitHub, and by Thursday morning it had about 785 points and 231 comments on Hacker News. It is a local emulator of the AWS APIs: you point the SDK or CLI at your own machine, and S3, DynamoDB, Lambda and friends answer from memory. There is no fee and no AWS account required. AWS's docs also say something I have not seen in a product page from a company this size: "AI agents keep the emulator up to date with AWS." For a solo builder who has been paying for LocalStack or testing against a real dev account, this is worth an hour. It is also worth reading the limits before you trust a green test run.
What it actually is
The README describes it as "a local emulator of the AWS APIs." It serves HTTPS on 127.0.0.1:9297 with a self-signed certificate. The code is under CC0 1.0, with vendored code under Apache 2.0, and the repo does not accept pull requests, only issues.
There are four ways to run it. On Linux you install an RPM or Debian package and run aws-emulator. On macOS and Windows you run it in a container from a short Dockerfile. Rust projects can embed it in-process as a dev-dependency. And there is an agent route: with AWS CLI 2.35.0 or later, aws agent-toolkit add-skill --skill-name aws-emulator adds it as a skill for your coding assistant.
AWS does not publish a total service count anywhere I could find. The docs use S3 and DynamoDB as examples, and release notes mention Lambda, CloudFormation, EC2, IAM, Step Functions, Bedrock, Cognito, Athena, SQS and SNS. The workspace has one crate per service, and the docs say it updates "many times a day." The releases page showed v1.0.322 as latest on November 11, published by a CI bot.
The limits that decide how you use it
This is the section I would read twice. The docs say plainly: "Don't use it for production workloads or to test security." Behind that line are concrete gaps:
- IAM and resource policies are not evaluated. A Lambda with no permission to read your bucket will read it anyway. A test that passes locally tells you nothing about whether your policies are right.
- One region, one account. Behavior is verified against us-west-2, or us-east-1 for global services. Cross-region or cross-account logic is out.
- State is in memory. Restart the emulator and your tables are gone. That is a feature for tests and a trap if you expected a persistent dev environment.
- No load or long-running tests. It is not a performance model of AWS.
The docs also say fidelity scores are published per release. On the releases page I checked, at least one recent release said scores were not available. So for now, "how close is this to real AWS" is something you measure yourself.
Telemetry is on until you turn it off
The telemetry page opens with "Telemetry is on by default." It collects random install and run IDs, OS and CPU, SDK name and version, region, install method, operation counts and outcomes, and "which AI coding assistant drives the emulator, if any." It says it does not collect request or response bodies, resource names, ARNs, credentials or account IDs. Data is batched every five minutes, sent to an AWS endpoint, and kept for up to 90 days.
I don't think this is sinister. It is a free tool and AWS wants to know which APIs people hit. But if you run it in CI for a client, or your contract says nothing leaves the build machine, turn it off. Any one of these works:
aws-emulator --telemetry off # or export EMULATOR_TELEMETRY=off
Or set enabled = false under [telemetry] in ~/.aws/emulator/config.toml. The docs say an "off" setting always wins.
The agent-maintained part
Some of the Hacker News discussion fixed on the AI angle, and coverage framed it as an emulator built by agents. AWS's own docs are more modest: agents keep it current with AWS, and the AGENTS.md file is written for "anyone, human or agent" editing it. I couldn't find a statement on how much human review the code gets, so I'm not going to claim one either way.
What I'd take from it is practical. An emulator that changes many times a day can change behavior under you between Tuesday and Wednesday. Pin a version in your Dockerfile or package install, the same way you pin any dependency, and bump it on purpose.
How I'd use it
For a typical solo stack (a Lambda or container, a DynamoDB table, an S3 bucket, a queue), I'd use the emulator for the inner loop: unit and integration tests that check my code calls the right APIs with the right shapes. That is where a real dev account costs time and money for no benefit.
Then I'd keep one small set of tests that runs against a real AWS account before deploys. Those cover exactly what the emulator skips: IAM policies, anything cross-region, and any behavior I've seen differ. If a test passes locally and fails in AWS, that's a bug report for the issues/ folder and a note in my own repo.
Where I could be wrong
If you already pay for LocalStack and it covers your services well, switching for free may not be worth the migration. LocalStack has years of fixes behind it, and AWS has published no fidelity numbers I could read. It's also possible AWS's team-plus-agents model produces something more accurate than a third party can, since it has the source of truth. I don't know yet. That's the point of pinning versions and keeping the real-account tests.
What I'd actually do
Install it this week on one project, turn telemetry off, pin the version, and point your existing integration tests at port 9297. Count how many pass unchanged. If it's most of them, you've cut your dev account usage and your test time. If it's fewer than you'd like, file the failures and keep using what you have. Either way, never let a local pass stand in for an IAM check.
Author
Lukas
@lukcombinator