AWS Emulator explained: test S3, DynamoDB and other AWS calls on your laptop, with no AWS account

AWS Emulator is a local program, made by AWS, that answers AWS API calls. You start it, point the AWS CLI or an AWS SDK at it, and run your code as usual. Your requests go to the emulator, not to AWS, so you work with emulated buckets, tables and queues instead of real ones. You do not need an AWS account, and AWS charges no fee for it.

AWS lists three uses: testing on your own machine, including calls that cross services; running integration tests in a CI/CD pipeline with no AWS account and no AWS resources; and letting AI coding agents build and try applications locally before they run on AWS. It has no graphical interface. It is a server that speaks the AWS wire protocols.

The source is on GitHub under the CC0 1.0 licence, with the vendored framework code under Apache 2.0. It is written in Rust, with one crate per AWS service, each driven by that service's Smithy API model. When we read the repository on 12 November 2026 it held 436 service crates. The first release on GitHub is v1.0.250, dated 7 November 2026, and new releases arrive several times a day.

Most cloud bugs live in the seams: a Lambda that writes to the wrong table, a queue message the consumer cannot parse, a bucket policy nobody tried. Unit tests with hand-written mocks rarely catch them, because a mock only returns what you told it to. Calling real AWS from every test run catches them, but it is slow, costs money and needs credentials in your CI.

An emulator sits between the two. Your integration tests make real API calls with real request shapes, and get back real AWS errors, but nothing leaves the machine. AWS's own example: try to create a DynamoDB table named ab, and the emulator rejects it with the same ValidationException and message that AWS returns, because table names need at least 3 characters.

That is the same reasoning behind every test environment in a well-designed system: make the cheap, fast loop as close to production as you can, and be precise about where it differs.

Read next: Integration testing: where most cloud bugs are actually caught

AWS calls it fidelity, and it measures it with fidelity tests: short programs that use an AWS SDK to run a workflow against a service and assert exactly what AWS does, including the resulting state and, for invalid calls, the exact error. The tests are built and verified against real AWS, and published in a separate repository, aws-emulator-evaluation-suite, including the ones the emulator does not pass yet.

A fidelity score is the number of those tests the emulator passes for one service, such as 40 of 50. Scores are published with releases, and AWS says passing tests do not regress. The failing count can still rise, because new tests find gaps that were already there. Compare scores only when they use the same version of the tests. AWS also says AI agents keep the emulator up to date with AWS, which is why the release notes are long lists of fixed gaps.

The practical advice from AWS is to check your own project rather than trust a headline number: its guide has a page on checking whether your project works with the emulator, and you can run the fidelity tests yourself against a local build.

Try it if your integration tests need S3, DynamoDB, SQS or other AWS services and today you either mock them by hand or call a real test account. The setup is a handful of environment variables, there is no fee, and the errors match AWS for implemented calls. If you already use a third-party emulator such as LocalStack, the fair test is to run your own suite against both and compare the failures, not a feature list.

Keep a small set of tests against real AWS anyway. Permissions, cross-Region behaviour, quotas and performance are exactly the things the emulator says it does not model, and they are where production incidents tend to come from. A sensible pipeline runs the fast emulator suite on every commit and the real-AWS suite before a release.

One more thing to know before you put it in CI: telemetry is on by default. AWS says it never includes your requests, responses, code or credentials, and you can turn it off with --telemetry off, EMULATOR_TELEMETRY=off, or a line in ~/.aws/emulator/config.toml.

Read next: The System Design course: testing, CI/CD and cloud architecture, from the ground up