Today AWS added a component called AWS Emulator that runs on a developer’s workstation and presents a local HTTPS endpoint exposing the same AWS APIs used by the CLI, SDKs, and AI‑driven coding agents. By installing a package (RPM/Deb) on Linux or a Docker container on macOS/Windows, the emulator generates its own credentials, configuration files, and a self‑signed certificate under ~/.aws/emulator/9297/. Setting a handful of environment variables redirects all AWS tooling to 127.0.0.1:9297, allowing existing scripts and test suites to operate unchanged while the emulator handles requests in‑process.
Why the Change Matters to Practitioners
AI engineers, platform teams, and SREs can now iterate on infrastructure code without provisioning real resources, eliminating cloud spend for unit‑level validation. The same workflow that creates a DynamoDB table or an S3 bucket in production can be exercised locally, which shortens feedback loops for coding agents such as Kiro or Claude Code. DevOps pipelines gain a deterministic stage that runs without network dependencies, and security engineers gain a sandbox where credential leakage is confined to a non‑production account (000000000000) with keys prefixed EMULATOR, reducing the risk of accidental exposure to real AWS accounts.
Architectural and Implementation Implications
The emulator is built in Rust and derives its service definitions from the public AWS API models repository. This design ensures that request shapes and error responses match those of the actual cloud services, but it also means the emulator only supports services that have a model in that repository. Running the emulator creates a local HTTPS server that listens exclusively on the loopback interface, so any process on the host can reach it if the environment variables are set. The generated configuration includes a ca.pem certificate that some SDKs must trust explicitly, often by adding it to a custom trust store.
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_PROFILEThese variables are the only bridge between existing tooling and the emulator; no code changes are required. The emulator writes JSON‑line logs that include request metadata, which can be consumed by observability pipelines for debugging or compliance audits.
Operational and Security Considerations
- Credential handling: The emulator’s keys are generated at start‑up and are not valid outside the emulator. Nevertheless, they should be treated as secrets while the emulator runs and cleared after use.
- Network exposure: Because the service binds to
127.0.0.1, it is not reachable from other hosts. Practitioners must avoid reconfiguring the bind address or forwarding the port, which would expose the emulator’s API surface. - Service coverage: Only APIs present in the AWS API models repository are emulated. Teams should verify that required services appear in the emulator before relying on it for integration tests.
- Certificate trust: Some SDKs require an explicit trust store entry for the emulator’s self‑signed CA. Failure to configure this can cause TLS errors that appear unrelated to the emulator itself.
- Logging and observability: The JSON log format can be ingested by existing log aggregation tools, but it may contain sensitive request payloads. Apply appropriate redaction if logs are forwarded off‑host.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Adopt the emulator as a first‑step validation layer in CI pipelines: start it, inject the environment variables, run unit and integration tests, then shut it down. Use the generated ca.pem to configure SDK trust stores, and treat the emulator’s credentials as short‑lived secrets. Verify service coverage against your application’s dependency list, and keep the emulator version aligned with the AWS API models you target. Finally, monitor the emulator’s logs for unexpected request patterns that could indicate misconfiguration or accidental use of real credentials.