AWS has made AWS Emulator generally available, giving developers a way to run selected AWS API interactions on a local machine before deploying applications to the cloud. The tool works with the AWS Command Line Interface (AWS CLI), AWS SDKs and coding agents through a local HTTPS endpoint, allowing existing code and tests to target the emulator by changing environment settings rather than application logic.
AWS says the emulator carries no additional service fee. It can be installed from RPM or Debian packages on Linux, run in Docker on macOS and Windows, or built from source. AWS does not publish a ready-made Docker image for the macOS and Windows setup described in its documentation.
Local endpoint, familiar development tools
When started, AWS Emulator generates credentials, a configuration file and a certificate in ~/.aws/emulator/9297/. Developers configure their tools to use the local endpoint, which listens at https://127.0.0.1:9297 by default. Because it binds to the local computer, other machines cannot reach it through that endpoint.
The setup can support existing command-line scripts and test suites as well as interactive development. AWS’s examples include creating an Amazon S3 bucket, uploading and listing an object, and using Amazon DynamoDB to create a table, write an item and retrieve it. In each case, the commands or SDK workflow run against the local emulator rather than requiring a deployment in an AWS Region.
Requests to the local-process emulator must be signed with Signature Version 4, as AWS requests are. The tool rejects requests signed with credentials other than its generated keys, whose access key IDs begin with EMULATOR. AWS advises developers to remove real credential variables from test environments and notes that some SDKs may require an additional setting to trust the emulator’s certificate.
Embedded mode for isolated tests
AWS also provides an embedded mode for tests written with the AWS SDK for Rust. Rather than connecting to a separate local server, a test instantiates the emulator in its own process and connects the SDK through an HTTP client. Each embedded instance maintains separate state, so parallel tests can avoid sharing resources such as buckets, tables or queues.
The embedded package is available as the aws-emulator-embedded crate on GitHub and is added to a Rust project’s development dependencies. AWS’s example uses it to create a DynamoDB table, write a record and read it back within a test. Embedded mode is specifically described for the AWS SDK for Rust; the local-process option is the broader approach for the CLI and SDKs.
Coverage measured against AWS behavior
AWS says the emulator is implemented in Rust and built from the AWS API models repository, which also informs the AWS SDKs. It supports APIs for services represented in those models, but coverage and behavioral fidelity vary by service and feature. Operations not implemented return HTTP 501, allowing tests to fail rather than silently treating unsupported behavior as successful.
The company measures fidelity with short SDK-based workflows and checks emulator results against real AWS. Its criteria include each call’s status code, response body and exact error code and message, along with the resources and data produced. AWS publishes per-service results as a passing-test count out of the total, and makes the evaluation suite—including tests that do not yet pass—available in a public GitHub repository. The scores are snapshots: adding new tests can lower a score even as implementation improves.
AWS says automated agents help maintain the emulator using AWS API models and services including Amazon Bedrock AgentCore Runtime Instances, AWS CodePipeline and AWS CodeCommit. The described process compares behavior with AWS and checks code against Smithy models, then creates issues for gaps. Changes are tested with fidelity checks before publication. AWS also says an independent security agent reviews changes during development and again in the release pipeline.
Important limits for production-bound systems
AWS cautions that the emulator does not evaluate AWS Identity and Access Management (IAM) policies or resource-based policies as AWS does. A request rejected by AWS could therefore succeed locally, making the emulator unsuitable for validating application security or permissions. AWS recommends testing security settings and the complete application against AWS before production.
Each emulator operates as a single account, identified in the example as 000000000000; it does not reproduce cross-account or cross-Region behavior. Developers should consult the published fidelity scores for the services and features they rely on, rather than assume that every AWS API behaves identically. AWS says anonymous usage and error data are sent by default, with an option to turn this off.
