AWS 发布本地模拟器 AWS Emulator 供开发者在本机测试应用

AWS Emulator 把 AWS 接口搬到本机

AWS 在 2026 年 11 月 11 日的 AWS News Blog 上，由 Daniel Abib 署名发布了 AWS Emulator。这是一个运行在开发者自己机器上的 AWS 本地模拟器。AWS CLI、各语言 AWS SDK 以及编码智能体，都通过本地 HTTPS 端点访问它，调用的仍是它们在云端使用的同一套 AWS 接口。AWS 称该工具没有额外的服务费用，只有在真正部署到 AWS 时才为云资源付费。源代码已在 GitHub 公开。Linux 上用 RPM 或 Debian 软件包安装；macOS 和 Windows 上则在 Docker 里运行。AWS 没有提供现成镜像，需要按文档里的简短 Dockerfile 自行构建。

本地运行的流程

使用方式很直接：安装软件包，启动 aws-emulator 命令，再让工具指向本地端点。启动时，模拟器会生成自己的凭据、配置文件和证书，并写入 ~/.aws/emulator/9297/ 目录。它在 127.0.0.1:9297 上提供 HTTPS 服务，所以只有本机能访问。随后你设置几个环境变量，比如 AWS_ENDPOINT_URL，并清除可能带来真实 AWS 凭据的变量。应用代码本身不用改。

每次启动，模拟器都会生成新的密钥。访问密钥 ID 以 EMULATOR 开头，不会和真实密钥混淆；用其他密钥签名的请求会被拒绝。它只使用一个账号，编号为 000000000000。文章里的演示先创建了一个 S3 存储桶并上传对象，再让 Kiro 编码智能体创建 DynamoDB 表、写入一条记录并读回，全部发生在本地端点上，没有动用真实账号。已有的测试套件也可以照此办理：启动模拟器，在测试脚本里设置同样的变量，然后照常运行。

面向测试的嵌入模式

测试场景还有第二种用法。嵌入模式允许在测试进程内部直接创建模拟器，并通过 SDK 的 HTTP 客户端接入。每个嵌入实例各自保存状态，因此测试之间不会共享存储桶、表或队列，可以大量并行。发布时，嵌入模式只支持 AWS SDK for Rust，通过 aws-emulator-embedded 这个 crate 使用。当模拟器作为独立进程运行时，部分 SDK 还需要额外设置来信任它的证书，文章举的例子是 AWS SDK for Java 的信任库。作为独立进程时，它要求每个请求都使用 SigV4 签名，并提供 /__admin/health 健康检查端点，方便脚本或容器等它就绪后再跑测试。

AWS 如何衡量保真度

模拟器只有在本地通过的测试到了 AWS 上也能通过时才有价值。为此 AWS 设计了保真度测试。每个测试是一小段程序，通过 AWS SDK 跑一套工作流，并断言 AWS 的行为。每个保真度测试都先在真实 AWS 上验证过。只有当模拟器在每一次响应上都与 AWS 一致，包括状态码、响应体、精确的错误码和错误信息，以及工作流创建出的资源，这个测试才算通过。每次发版，AWS 都按服务公布 k/n 形式的得分。测试集合在 aws-emulator-evaluation-suite 仓库中公开，包括尚未通过的用例。AWS 也提醒，新增测试后得分可能下降，即使模拟器本身在改进。如果某个操作尚未实现，模拟器会返回 HTTP 501，让测试立刻失败，而不是意外通过。

由智能体构建并审查

AWS 称，模拟器由智能体根据 AWS API 模型构建和维护，使用 Amazon Bedrock AgentCore Runtime Instances、AWS CodePipeline 和 AWS CodeCommit。一组智能体负责发现差距并为每个差距提交问题；另一组负责写测试、实现行为并审查改动。改动推送后会触发流水线，先运行保真度测试，再发布到公开仓库。一个独立的安全智能体会在修复阶段和发布流水线中以对抗方式审查变更。这些都是 AWS 对自身流程的说法，文章没有提供第三方审计。

需要预先考虑的限制

文章对限制说得很直接。模拟器不会像 AWS 那样评估 IAM 策略和资源策略，所以 AWS 会拒绝的请求，在本地可能成功。AWS 明确建议不要用它来测试应用是否安全。每个模拟器只相当于一个账号，没有跨账号或跨区域行为。与 AWS 的接近程度因服务和功能而异，请查看你所用服务的保真度得分。默认情况下它会发送匿名的使用和错误数据，可以关闭。文章下方有一位读者在同一条评论中提出了每次启动证书会重新生成，以及 .NET SDK 分块签名 S3 上传内容存储有问题等情况。这些是未经独立验证的用户反馈，不是 AWS 的声明，在 AWS 回应之前应视为未经证实。

对开发者意味着什么

对目前直接用真实 AWS 账号做测试的团队来说，一个足够忠实的本地端点可以降低成本、减少等待，也让编码智能体有安全的地方反复试错。代价是：本地全部通过并不等于生产环境一定正常，安全规则尤其如此。请把真实凭据挡在测试任务之外，并在上线前到 AWS 上做最后的检查。