1. What AWS Emulator is — and why it suddenly blew up

AWS Emulator is a local emulator of the AWS APIs, released under the CC0-1.0 public-domain dedication (the vendor/ directory is Apache-2.0). You start it on your own machine, point the AWS CLI or an AWS SDK at its local endpoint, and run your code as usual — your requests go to the emulator, not to AWS. There is no graphical interface and no additional service fee: you pay only for real AWS resources when you deploy on AWS. It is written in Rust, serves HTTPS on 127.0.0.1:9297 with a self-signed certificate, and covers the APIs of the AWS services that have an API model in the AWS API models repository — over 200 services, according to AWS.

The numbers behind the surge: the GitHub repo aws/aws-emulator showed 4,450 stars when we checked on November 12, 2026, and its Hacker News post reached 922 points with 254 comments. AWS also says something unusual about how it was built: autonomous AI agents wrote every line of the code, and its engineers did not review it — an independent security agent reviews changes instead. That claim alone is worth a hands-on check rather than a summary of other people's posts, so we ran one — on our own machine, with our own test data.

2. How to install it — the exact steps we ran

Requirements (from the official docs): Linux x86_64 or aarch64 for the native package (macOS and Windows run it in Docker), plus AWS CLI version 2.35.0 or later to talk to it. Our test ran on Ubuntu 24.04 (x86_64) on November 12, 2026.

Step 1 — Download the Debian package from AWS. The official "Getting started on Linux" page gives this exact command. Watch the file name: the Debian package is aws-emulator_amd64.deb — the name aws-emulator-x86_64.deb does not exist (we tried it and got a 403). The RPM package is the one called aws-emulator-x86_64.rpm.

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

Step 2 — Verify the signature before you install (optional, but we did it). AWS signs each package; the signature file sits next to the package with .sig added. We downloaded it and the AWS publishing key, and the fingerprint matched the one in the docs exactly — 98BC F336 A3BE 53B7 34E9 67C5 2E5B F49B D940 F624 — and gpg --verify reported Good signature from "SSM Publishing <ssm-publishing@amazon.com>".

curl -fsSLO https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest/aws-emulator_amd64.deb.sig
curl -fsSLo aws-publishing.asc https://downloads.aws.com/keys/gpg/current.asc
gpg --import aws-publishing.asc
gpg --verify aws-emulator_amd64.deb.sig aws-emulator.deb

Step 3 — Confirm the version. The package installs the emulator in /opt/aws-emulator/ and adds the aws-emulator command to /usr/bin/. Ours printed:

aws-emulator -v
# Version: 1.0.322
# Release date: 2026.11.10
# Commit: 7753983c6e495ec3612695b1336bf4936fc7b7fd

Note the version: the LTS package channel served 1.0.322 even though the GitHub releases page already listed v1.0.336 the same day. If you need a specific version, the docs have a "Finding and installing a specific version" page — don't assume "latest" means the newest tag.

Step 4 — Install the AWS CLI v2 (we had none on this machine) from the official installer:

curl -fsSLo awscliv2.zip https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip
unzip awscliv2.zip
sudo ./aws/install
aws --version
# aws-cli/2.40.1

Step 5 — Start the emulator and point your shell at it. We started it with telemetry off (see the safety section — telemetry is on by default). It was answering health checks about 2 seconds later. The environment variables below are the ones from the official AWS blog post; they make the CLI use the emulator's own generated credentials instead of any real AWS credentials, so unset yours first.

aws-emulator --telemetry off
curl --cacert ~/.aws/emulator/9297/ca.pem https://127.0.0.1:9297/__admin/health
# ok

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
export AWS_DEFAULT_REGION=us-east-1
export AWS_CA_BUNDLE=~/.aws/emulator/9297/ca.pem
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE

3. Our hands-on test: S3, DynamoDB and SQS, for real

Target: the same quick loop the official blog post demonstrates — prove the CLI is talking to the laptop, store a file in S3 and read it back byte-for-byte, write and read a DynamoDB item, and send and receive an SQS message. Every value below is what the emulator itself reported back, not what we typed in and assumed. All test data is our own.

Identity check — are we really talking to the laptop?

aws sts get-caller-identity
# {
#     "UserId": "AIDAH5I7GEMO7ADXNFAZU",
#     "Account": "000000000000",
#     "Arn": "arn:aws:iam::000000000000:user/emulator"
# }

The emulator uses a single account, 000000000000, and generates fresh keys every time it starts — key IDs start with EMULATOR, so you can't mistake them for real AWS keys, and it rejects requests signed with any other keys.

S3 — bucket, upload, list, download, compare

echo "hello from the emulator" > hello.txt
aws s3 mb s3://local-getting-started
# make_bucket: local-getting-started
aws s3 cp hello.txt s3://local-getting-started/
# upload: ./hello.txt to s3://local-getting-started/hello.txt
aws s3 ls s3://local-getting-started/
# 2026-11-12 16:26:05         24 hello.txt
aws s3 cp s3://local-getting-started/hello.txt hello-back.txt
diff hello.txt hello-back.txt   # no differences — S3 round-trip OK

DynamoDB — the one that caught us out

aws dynamodb create-table --table-name kiro-demo \
  --attribute-definitions AttributeName=id,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST
# table: kiro-demo, status: CREATING
aws dynamodb put-item --table-name kiro-demo \
  --item '{"id": {"S": "item-1"}, "msg": {"S": "hello from kiro"}}'
# ERROR: ResourceNotFoundException — Requested resource not found

The table was still CREATING when we wrote to it, and the write failed. After about 10 seconds, describe-table reported ACTIVE — and then the same put-item and get-item worked, reading back exactly what we wrote:

aws dynamodb get-item --table-name kiro-demo --key '{"id": {"S": "item-1"}}'
# { "Item": { "id": {"S": "item-1"}, "msg": {"S": "hello from kiro"}} }

Lesson for your own tests: wait for the table to become ACTIVE before you write. Poll describe-table in your test script; don't assume create means ready.

SQS — send it, receive the same message back

aws sqs create-queue --queue-name demo-queue
# queue: https://sqs.us-east-1.amazonaws.com/000000000000/demo-queue
aws sqs send-message --queue-url https://127.0.0.1:9297/000000000000/demo-queue \
  --message-body "test-message-42"
# msg id: cc18857c-a158-4c75-87a0-0df852c1df83
aws sqs receive-message --queue-url https://127.0.0.1:9297/000000000000/demo-queue
# received: test-message-42

One deliberate failure — what happens on an unimplemented service

The docs say an operation the emulator hasn't implemented returns HTTP 501 (Not Implemented), so your tests fail loudly instead of passing silently. We tried Import/Export, which has no model in the emulator at all, and got a JSON error instead of a clean 501: {"__type":"UnknownService","message":"no emulated service is registered for 'ingestionservice'"}, which the CLI reported as a malformed response. It still failed loudly — nothing passed silently — but the error shape doesn't match the documented 501. Worth knowing before you wire it into CI: assert on the failure, not on the exact error text.

What we checked	Result
Install from the official Debian package, signature verified	Passed. GPG fingerprint matched the docs exactly; aws-emulator -v printed 1.0.322.
Startup and health endpoint	Passed. Healthy in ~2 seconds; /__admin/health returned ok.
STS identity is the local account	Passed. Account 000000000000, user emulator.
S3: create bucket, upload, list, download, byte-compare	Passed. 24-byte file came back identical.
DynamoDB: create table, put item, read it back	Passed, with a catch. The table needs ~10 seconds to reach ACTIVE; writing while it is CREATING fails with ResourceNotFoundException.
SQS: create queue, send, receive	Passed. Received test-message-42 verbatim.
Unimplemented service fails loudly	Partially as documented. It failed, but with a JSON UnknownService error rather than the documented HTTP 501.

Our verdict: the core loop is real — install, start, point the CLI at your laptop, and S3, DynamoDB and SQS behave the way the docs say they should, with one honest timing quirk on DynamoDB table creation. For a tool that is one day old, that is the part that matters most. The rough edges are honest ones — see the next section — not hidden ones.

4. What AWS Emulator can't do (yet) — the limits, stated plainly

• Don't use it to test security. AWS says so explicitly, and it matters: the emulator does not evaluate IAM policies or resource-based policies the way AWS does, so a request AWS would deny can succeed locally. A green test here is not proof your production setup is secure.
• Don't use it for production workloads. It is for building and testing only. Everything lives in memory — when you stop the emulator it deletes its files and all emulated resources disappear. (We confirmed this: after stopping, ~/.aws/emulator/9297/ was empty.)
• DynamoDB tables aren't writable the instant they're created. Create returns CREATING; writing too early fails with ResourceNotFoundException. Wait for ACTIVE — about 10 seconds in our test.
• Fidelity varies by service. AWS publishes a fidelity score per service with each release (k of n tests passing), and tracks 6,545 known gaps in the repo's issues/things-that-do-not-work/ directory. Before you rely on it for a service, check that service's score — a passing test on one service says nothing about another.
• One account, one region at a time. Every emulator is a single account (000000000000) with no cross-account or cross-region behaviour.
• Telemetry is on by default. The emulator reports anonymous usage data to AWS unless you turn it off with --telemetry off or EMULATOR_TELEMETRY=off. Our startup log confirmed telemetry was disabled when we passed the flag.
• Unimplemented operations don't always fail the way the docs say. We saw a JSON error where the docs promise HTTP 501. It still fails loudly, but don't assert on the exact error.
• What we didn't test: Lambda, EC2, embedded mode (Rust), the Docker path, macOS/Windows, building from source (the README says a full build wants at least 100 GB of disk for target/), and the AI coding-agent skill. The docs cover them; we don't claim them.

5. Safety — read this before you install anything

• Use only the official sources: the GitHub repo aws/aws-emulator, the package host downloads.aws.com, and the AWS CLI installer at awscli.amazonaws.com. We verified the package signature against the fingerprint published in the AWS docs before installing.
• Verify the package if you install it. The GPG fingerprint must be 98BC F336 A3BE 53B7 34E9 67C5 2E5B F49B D940 F624. If it differs, don't install the package.
• Keep real credentials out of the emulator's environment. Unset AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN and AWS_PROFILE before you run tests, and point the CLI at the emulator's own generated credentials file. The emulator rejects requests signed with any other keys, but the habit is what protects you.
• Turn telemetry off if you don't want it. It is on by default; aws-emulator --telemetry off disables it for that run.
• It only listens on your own machine by default (127.0.0.1:9297), and it only accepts requests signed with its own freshly generated keys. Don't expose the port or share the generated credentials.
• Test only your own code and data. The emulator is a testing tool for your own software. Don't use it to probe anyone else's systems, and don't test security settings here — test those on AWS before production.
• Free means free here. There is no account, no licence key and no service fee; AWS makes its money when you deploy. The code is CC0-1.0 (public-domain dedication), so you can use and explain it freely.

6. FAQ

Is AWS Emulator really free?

Yes — no service fee, no AWS account, no licence key. AWS says you pay only for AWS resources when you deploy on AWS. The source is CC0-1.0, a public-domain dedication, so there is nothing to buy and no paid tier to unlock.

Do I need an AWS account?

No. The emulator generates its own credentials and writes them to ~/.aws/emulator/9297/ when it starts. Your requests never leave your machine. You only need an account when you deploy for real.

Is it a replacement for LocalStack?

It solves the same problem — test AWS code without touching AWS — but it is AWS's own official emulator, built from the same API models the SDKs use, with published per-service fidelity scores and a public list of known gaps. Whether it replaces LocalStack for you depends on which services you use: check the fidelity score for your services before switching. We tested S3, DynamoDB and SQS only.

Why did my DynamoDB put-item fail right after create-table?

Because the table was still CREATING. In our test, writing immediately after create-table failed with ResourceNotFoundException, and the table became ACTIVE about 10 seconds later — then the same put-item worked. Wait for ACTIVE (poll describe-table) before writing.

Can I use it to check whether my app is secure?

No — AWS is explicit about this. The emulator doesn't evaluate IAM or resource-based policies the way AWS does, so a request that AWS would deny can succeed locally. Test your security settings on AWS before production.

What happens to my test data when I stop it?

It disappears. The emulator keeps everything in memory, and stopping it deletes its files and all emulated resources. Treat every run as a fresh, empty AWS account — which is exactly what makes it good for repeatable tests.

Want a site built with tools like this?

AWS Emulator is the kind of free, official tool we use when we build websites for small businesses — practical, no subscription, and it does the job it promises. See our website service, or browse our free tools — QR codes, invoices, colour tools and more, all running locally in your browser.