AWS announced the general availability of AWS Emulator on November 11, 2026, giving developers a local endpoint for AWS CLI and SDK requests without requiring an AWS account for the local test loop. It runs on your machine, has no additional service fee, and supports existing application code through endpoint configuration. Normal AWS charges apply when you deploy resources to the cloud. (AWS launch announcement)
AWS also says thousands of autonomous agents wrote every line of the emulator and continue to maintain it, without human code review. That makes this an unusually concrete agent-engineering disclosure, attached to a downloadable developer tool.
The practical distinction matters immediately: AWS-compatible requests do not guarantee AWS-equivalent behavior. The emulator can accelerate development, but its permission handling and incomplete service implementations leave some tests firmly in real-AWS territory.
Install AWS Emulator and Connect Your Tools
AWS provides three installation paths:
| Platform | Installation path |
|---|---|
| Linux | Native RPM or Debian package |
| macOS | Build and run a Docker container |
| Windows | Build and run a Docker container |
AWS does not publish a ready-made Docker image. macOS and Windows users need to build one using the Dockerfile linked from the launch guide.
Start the Local Server
AWS’s documented Amazon Linux 2023 example installs the x86-64 RPM, checks the installed version, and starts the emulator:
PKG=https://downloads.aws.com/aws-emulator/packages/aws-emulator/LTS/latest
sudo dnf install -y "$PKG/aws-emulator-x86_64.rpm"
aws-emulator -v
aws-emulator
These commands are the published setup path, not a test performed for this article.
The server listens over HTTPS at 127.0.0.1:9297. That loopback address keeps the native process’s endpoint reachable only from the same computer. At startup, the emulator generates credentials, configuration, and a certificate under:
~/.aws/emulator/9297/
Keep the server running, then configure a second terminal for your CLI commands or test runner.
Point the CLI and SDKs at Local AWS
AWS supplies this environment configuration:
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
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_PROFILE
The endpoint variable redirects requests to the emulator. The credentials and configuration paths select its generated files, while unsetting existing credential variables removes possible sources of real AWS credentials. The other settings disable EC2 metadata credential discovery and SDK host-prefix injection.
New keys are generated whenever the emulator starts. Their access key IDs begin with EMULATOR, and the emulator rejects requests signed with other keys. It uses the single account ID 000000000000. (AWS setup documentation)
I’d use a dedicated terminal or test-runner script for this configuration. It makes the destination explicit and reduces confusion when switching between local tests and actual AWS accounts.
Check the endpoint and caller identity with:
curl --cacert ~/.aws/emulator/9297/ca.pem \
https://127.0.0.1:9297/__admin/health
aws sts get-caller-identity
The first command checks health while trusting the generated certificate. The second checks the identity exposed through the configured AWS endpoint. Some SDKs require additional certificate-trust configuration; AWS specifically notes a trust store for the Java SDK. Disabling TLS verification should not be the default workaround.
Try a Small Storage Workflow
AWS demonstrates this S3 sequence:
aws s3 mb s3://local-getting-started
echo "hello from the emulator" > hello.txt
aws s3 cp hello.txt s3://local-getting-started/
aws s3 ls s3://local-getting-started/
It creates a bucket, writes a local file, uploads it, and lists the bucket’s contents. The commands are ordinary AWS CLI operations; the environment configuration changes where they run.
An existing test suite can use the same arrangement: start the emulator, configure the test process, and run the tests. A coding agent must also inherit that configuration to use the local endpoint.
What AWS Emulator Supports, and What That Means
AWS Emulator is implemented in Rust and draws its API surface from the AWS API Models repository, which also supplies models used by AWS SDKs. AWS describes starting with a server capable of handling requests for 438 API models. That figure describes modeled API coverage, not 438 fully implemented services. (AWS engineering account)
The launch material demonstrates S3 bucket and object operations and DynamoDB table creation, item writes, and reads. AWS’s engineering account also describes an SQS fidelity test covering queue creation, message sending, receiving, acknowledgment, and deletion.
The useful distinction is between request compatibility and behavioral fidelity:
| Area | Documented behavior | Testing consequence |
|---|---|---|
| Requests and errors | Built from AWS API models to match AWS API shapes | Existing SDK calls can target the emulator |
| Unimplemented operations | Return HTTP 501 | A modeled API may still lack an implementation |
| Service fidelity | AWS publishes per-service scores | Check the relevant service and workflow |
| IAM and resource policies | Evaluation differs from AWS | Cloud-denied requests may succeed locally |
| Accounts and Regions | Cross-account and cross-Region behavior is not modeled | These interactions need cloud validation |
AWS’s fidelity scores are vendor-published measurements, not independent benchmarks. They can help identify coverage, but they should be read alongside the particular operations your application depends on. (AWS coverage and limitations)
A Passing Test Is Not a Permission Check
The IAM difference is the most consequential limitation for application teams. A successful local request cannot demonstrate that a production role has the required permissions. It also cannot establish that a restrictive policy will block an unwanted action.
The same distinction applies to the Region variables in the setup example. They configure the SDK’s requests; they do not make the emulator reproduce cross-Region behavior.
My recommendation is to split tests by what they prove. Use local tests for supported application workflows, request construction, and response handling. Keep real-AWS tests for IAM policies, account boundaries, Region interactions, and other behavior that the emulator does not reproduce.
Rust Tests Can Run In-Process
The AWS SDK for Rust has an additional option: embedded mode. Tests instantiate the emulator inside the test process and connect it through the SDK’s HTTP client, avoiding a separate HTTPS server.
Frequently Asked Questions
3 questions
1Is AWS Emulator Free?
AWS charges no additional service fee for the emulator. Running the local loop does not require an AWS account, but deploying resources to real AWS incurs normal charges.
