Jorge Turbica / blog · Blog ← All articles ES · Leer en español
Cloud

AWS ships a free local emulator with no account needed, filling the LocalStack gap

AWS Emulator runs S3, DynamoDB and more on your laptop, free and with no account. How it compares to LocalStack, and why it can't test IAM.

An official AWS emulator that runs on your laptop, speaks the same APIs as the cloud and costs nothing. AWS launched AWS Emulator on November 11, 2026, generally available from day one, almost eight months after LocalStack stopped maintaining its free Community edition and started requiring an account and token to run its image.

If you have integration tests against S3, DynamoDB or SQS, the question is no longer just "LocalStack or mocks", but whether the cloud provider's own emulator is good enough.

What it is and how it works

AWS Emulator is a Rust binary that serves an HTTPS endpoint on 127.0.0.1:9297. The AWS CLI, the SDKs and coding agents talk to it as if it were AWS: point AWS_ENDPOINT_URL at it and your application code stays the same.

The interesting part is how it is built. It isn't hand-written service by service: it is generated from the Smithy models AWS publishes, the same ones the SDKs come from, so requests and errors have the same shape as in the cloud. The repository has one crate per service and is maintained by agents. Some look for gaps by comparing responses with real AWS and file an issue for each; others write the tests, implement the change and review it, and a security agent reviews changes before they ship.

A few details that matter when you wire it into CI:

  • On startup it generates its own credentials, a config file and a certificate in ~/.aws/emulator/9297/. Access keys start with EMULATOR and it rejects any request not signed with them (SigV4), which makes it hard to hit a real account by mistake.
  • Everything lives in memory: about 160 MiB idle, and stopping it deletes the resources and its files.
  • It emulates a single account (000000000000), with no cross-account or cross-Region behavior.
  • It exposes /__admin/health on the same port so your pipeline can wait until it is ready.
  • Unimplemented operations return 501, so a test fails instead of passing by accident.

How to try it

On Linux you install a package (RPM or Debian, x86_64 and ARM). On macOS and Windows you build a Docker image from the Dockerfile in the docs, because AWS doesn't publish a ready-made one.

bash
# Debian/Ubuntu (amd64)
curl -fsSLo aws-emulator.deb https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest/aws-emulator_amd64.deb
sudo apt-get install -y ./aws-emulator.deb

# Fedora, RHEL or Amazon Linux 2023 (x86_64)
sudo dnf install -y https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest/aws-emulator-x86_64.rpm

aws-emulator --telemetry off

In another terminal, point the CLI at the emulator and clear any real credentials from the environment:

bash
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_EC2_METADATA_DISABLED=true
export AWS_DISABLE_HOST_PREFIX_INJECTION=true
export AWS_REGION=us-east-1
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE

aws sts get-caller-identity
aws s3 mb s3://local-tests

Telemetry is on by default; --telemetry off or EMULATOR_TELEMETRY=off turns it off. To run several emulators side by side, -p 0 picks a free port and each instance keeps its files in its own directory.

There is a second, embedded mode that puts the emulator inside your test process: each test gets its own instance, with no port or certificate, and tests can run in parallel without sharing tables or buckets. For now it only exists for the Rust SDK (the aws-emulator-embedded crate) and it is not cheap: it compiles one crate per service, and the README asks for at least 100 GB free for target/. In CI you will want to cache target/ or use sccache.

AWS Emulator vs LocalStack

LocalStack was the default answer for emulating AWS locally. Since March 23, 2026, its single Docker Hub image requires an account and an auth token, and its free plan does not allow commercial use.

AWS EmulatorLocalStack for AWS
PriceNo chargeFree plan for non-commercial use only; paid plans for companies
Account to startNoYes, account and auth token
CodePublished on GitHub, CC0-1.0 licenseCommunity edition unmaintained since March 2026
DistributionRPM and Debian on Linux; Docker image you build on macOS and WindowsDocker Hub image
In-process testsYes, Rust SDK only—
How fidelity is measuredPublic fidelity tests, with a "k of n" score per service on each release—

Where AWS Emulator wins. Price and license, first of all: a team that used LocalStack Community at work had to pay or stay on a frozen version, and now has an alternative from the provider itself. Being generated from the Smithy models is a structural advantage: a new service or API change can reach the emulator without anyone hand-coding it. And publishing the fidelity tests, including the failing ones, lets you check whether your services are covered before you migrate.

Where it loses. Maturity. AWS Emulator has just shipped and its own docs admit fidelity varies by service and feature. There is no official Docker image either, so on macOS and Windows you build and maintain one yourself.

The caveat that matters: IAM is not evaluated

AWS is explicit about it: the emulator does not evaluate IAM policies or resource-based policies the way AWS does, so a request AWS would deny may succeed locally. A green test against the emulator tells you nothing about permissions. AccessDenied errors from a badly written policy, one of the most common deployment failures, will still show up in your first real environment. Permission and security tests have to keep running against an AWS account.

Verdict

Who it's for: teams with integration tests against common services (S3, DynamoDB, SQS) who were paying for LocalStack just for that or got stuck on the last Community release; anyone using coding agents who wants them to create and delete resources without touching an account; Rust projects, which get isolated, parallel tests with embedded mode.

Who should wait: anyone relying on less common services or on cross-account or cross-Region behavior, and anyone who needs to validate IAM locally. The sensible move is to check the fidelity tests for each service you use and, if they hold up, migrate a non-critical pipeline first.

Sources

Jorge Turbica

Software Engineer and SRE. I write about the real challenges I run into in production.

See portfolio ↗