AWS Emulator 开源：438 个 API 模型本地跑与 59.71% 保真度

一句话结论：AWS 在 11 月 11 日正式发布开源工具 AWS Emulator，一套用 Rust 写的本地 AWS API 模拟器，覆盖 438 个服务的 43548 项保真度测试中已有 26001 项通过，通过率 59.71%，开发者可以在自己的机器上跑完整的 AWS CLI 与 SDK 流程，不必消耗任何云上配额。

过去要在本地验证一段云上代码，通常只有两条路：自己搭一套精简桩实现，或者干脆去测试账号里反复调用真服务。前者意味着为每个服务维护一套实现，接口一升级就得跟着改；后者要处理配额、权限与真实账单。AWS Emulator 把官方 API 模型直接变成可本地调用的端点，走的是第三条路。

官方博客文章《Test your applications against AWS locally with AWS Emulator》由 AWS 高级解决方案架构师 Daniel Abib 撰写，发布于 2026 年 11 月 11 日，文章在 11 月 12 日补充了 GitHub 仓库链接。工具本身已在 GitHub 开源，仓库地址是 aws/aws-emulator，公开当天星标数已超过 5000。

它是什么：不是 LocalStack 的另一版

AWS Emulator 是一个本地程序，对外提供 AWS API 端点，没有图形界面。安装启动之后，把环境变量指向本地端点，AWS CLI、AWS SDK 与你的代码保持原样运行。仓库用 Rust 实现，官方强调的动机是让 CPU 与内存占用在笔记本上保持轻量。

关键设计在于它直接消费 AWS 官方的 API 模型仓库 aws/api-models-aws，也就是 AWS SDK 自己用的那套 Smithy 模型。因此请求与返回错误的形状跟线上完全一致。没实现某个操作时，模拟器直接返回 HTTP 501 与 NotImplemented 错误码，测试会立刻失败，而不是给出一个假的成功响应。

它支持凡是 AWS API 模型仓库里有 API 模型的服务，目前对应 438 个服务 crate，覆盖面远超一般意义上的 mock 工具。

三种接入方式与完整命令

最常见的是服务端模式。Linux 上装 RPM 或 Debian 包后直接跑命令，macOS 与 Windows 则用一个短 Dockerfile 构建镜像在容器里运行，官方不发布预制镜像：

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

启动后模拟器在 127.0.0.1:9297 上提供 HTTPS 服务，并把凭据、配置文件与证书写到 ~/.aws/emulator/9297/。另一个终端里设置环境变量，并确保真实凭据不污染环境：

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

健康检查与调用方身份确认：

curl --cacert ~/.aws/emulator/9297/ca.pem https://127.0.0.1:9297/__admin/health
aws sts get-caller-identity

之后建桶、传对象、列表都是原生 AWS CLI 语法，无需改代码：

$ 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

第二种是嵌入式模式，适合写测试。直接实例化在测试进程内，把模拟器的 HTTP 客户端接给 SDK，不需要端点 URL、证书与环境变量。每个实例拥有独立状态，测试之间不共享桶、表与队列，可以并行跑多个。目前只支持 AWS SDK for Rust：

use aws_emulator_embedded::{AwsEmulatorEmbedded, EmbeddedOptions};

let emulator = AwsEmulatorEmbedded::new(EmbeddedOptions::default());
let config = aws_config::defaults(aws_config::BehaviorVersion::latest())
    .http_client(emulator.http_client())
    .region(aws_config::Region::new("us-east-1"))
    .credentials_provider(emulator.aws_credentials_provider())
    .load()
    .await;

第三种是配合编码智能体使用。官方提供了 aws-emulator 技能包，一条命令即可装给智能体，需要 AWS CLI 2.35.0 或更高版本：

aws agent-toolkit add-skill --skill-name aws-emulator --region us-east-1

官方博客的演示里，作者让 Kiro 在本地环境创建 DynamoDB 表、写入一条记录再读回来，全程不接触真实 AWS 账户。这种用法与Co-Design Bench 里编码智能体 26.4% 全对率的实测指向同一个问题：智能体要能反复验证自己的产出，就得有便宜可重复的验证环境。

保真度实测：43548 项测试与 59.71% 通过率

模拟器有没有用，取决于「在它上面通过的测试，放到真 AWS 上是否也通过」。AWS 用保真度测试直接测量这一点。每个保真度测试是一个用 AWS SDK 驱动真实工作流的短程序，比如存一个对象再读它并删除，然后断言 AWS 的行为。测试必须在状态码、响应体、错误码与错误消息、以及工作流创建的资源与数据上全部与真 AWS 一致才算通过。

测试集本身是公开的，放在 aws/aws-emulator-evaluation-suite 仓库，包含目前还没通过的用例。仓库里有 manifest.jsonl 清单文件，记录每个测试调用的服务、操作与标签，还配了一个 Python 运行器 fidelity_tests_runner，可以自己跑一遍复现官方分数。

我们下载了 v1.0.338 版本随附的官方分数文件 scores.json.gz 做了独立统计。这份文件的记录时间是 2026 年 11 月 12 日，覆盖 349 个服务：

整体口径是 43548 个测试单元，其中 26001 个通过、17464 个失败、83 个跳过，通过率 59.71%。官方博客在 11 月 12 日的补充里也提到这个 56.6% 的对外数字，与我们按最新发布版分数文件统计出的 59.71% 存在小幅差异，原因在于测试集本身在持续增补，新加的测试可能一上来就暴露既有差距。

分服务的分布比总体数字更有参考价值。S3、DynamoDB、Step Functions 这些最常用的服务通过率都在 70% 以上，而 CloudFormation 只有 19.4%、EC2 只有 44.6%。官方文档明确说控制面 API 匹配得最好，数据面 API 与基础设施即代码工具的支持因服务而异。AWS Emulator 官方保真度文档也提醒，分数是一个快照，随着测试集增补，总数与通过数都会涨，看分数必须固定同一版本的测试集才有可比性。

不能做什么：安全测试与多区域

官方在多处强调了这套工具的能力边界。模拟器不按 AWS 的方式评估 IAM 策略与资源策略，所以在 AWS 上会被拒绝的请求在模拟器里可能成功。它是开发和测试工具，不是安全测试工具，官方文档里直接写了不要用它来测试应用是否安全。

其它限制包括：每个模拟器实例只对应一个账户，账户号固定为 000000000000，不区分区域，跨区域与跨账户行为都不模拟；要测多个区域得分别起多个实例并分配不同端口。保真度验证只在 us-west-2 区域进行，全球性服务则在 us-east-1 验证，区域间的服务可用性差异不反映。资源全部存在内存里，模拟器重启即清空。此外每个请求都必须用 SigV4 签名，模拟器每次启动生成新密钥，访问密钥 ID 以 EMULATOR 开头，用别的密钥签名的请求会被直接拒绝。

遥测默认开启，收集匿名的使用与错误数据，可以关掉：

aws-emulator --telemetry off
# 或
export EMULATOR_TELEMETRY=off
# 或在 ~/.aws/emulator/config.toml 里写 [telemetry] enabled = false

这些限制与站内AWS Infinity 运行时的 8GB 内存实测形成有意思的对照，一个是把云上接口搬到本地跑，一个是把智能体运行时压到单台设备上，两者都在解决本地验证与本地承载的问题。

它是怎么被造出来的

最特别的一点是，AWS Emulator 的代码是由智能体写的。官方说明，构建与维护由运行在 Amazon Bedrock AgentCore Runtime Instances 上的智能体群完成，配合 AWS CodePipeline 与 AWS CodeCommit，确保它随官方 API 模型的变化保持同步。

流水线分成两组智能体。一组专门找差距，既把模拟器响应与真 AWS 逐一对比，也把模拟器代码与公开的 Smithy 模型做静态比对，每发现一个差距就开一个 issue。另一组接手 issue，写测试、实现行为、审查正确性、性能与安全性。代码推到源仓库后触发 CodePipeline 跑一遍保真度测试，通过后才发布到公开仓库。

因为代码由智能体产出，AWS 额外安排了一个独立的安全智能体做对抗式审查，修复过程中审查一次，发布流水线里再审一次。仓库不接收 pull request，所有变更都通过这条智能体流水线完成。

这种用智能体维护基础设施的做法，跟LobeHub Agent 自改 harness 的 70% 通过率实测是同一条技术路线上的实践，风险与收益的边界也相似：产出速度极快，但验证环节必须由独立的评价体系兜底，AWS 用的正是保真度测试。

上手成本与构建代价

大多数用户装预编译包就行，但从源码构建的门槛不低。官方要求 Rust 工具链与 Cargo、一个 C 编译器、至少 100GB 的空闲磁盘用于 target 目录，还需要多核机器。原因是工作区每个服务一个 crate，全量 debug 构建体积相当可观，随着服务增加还会继续变大。冷启动全量编译所有服务 crate 耗时较长，核心数越少越慢，之后只改一个服务重建会快得多。

嵌入式模式因为要把模拟器编译进测试二进制，项目第一次 cargo test 会同时构建模拟器的全部服务 crate，构建预算与从源码构建同一量级。官方建议跨项目复用同一个 CARGO_TARGET_DIR，在 CI 里缓存 target 目录或使用 sccache，并把模拟器锁定到某个 release commit，避免每次改动都重编。

对于本地跑模型这条需求，站内DeepSeek Harness 接本地 Ollama 的踩坑记录里整理了常见的三类崩溃原因，可以对照本地服务的启动顺序与端口配置一起看。

常见问题

AWS Emulator 能替代真实 AWS 账户做测试吗？

能覆盖大部分开发与集成测试场景，而且不需要 AWS 账户、不消耗云上配额、不产生费用。但保真度只有约六成，CloudFormation 与 EC2 等服务差距更大，所以它适合做编排逻辑、失败重试与额度控制的本地调通，最终验证仍应回到真实环境。涉及安全策略的测试绝对不能只靠它。

本地模拟与自建桩实现该怎么选？

关键看接口是否还在演进。自建桩实现的维护成本随服务数量线性增长，官方接口一升级就得跟着改，而 AWS Emulator 直接消费官方 Smithy 模型，协议形状天然跟着上游走。代价是要接受约 60% 的保真度上限，以及 Rust 构建带来的资源开销。若只需要覆盖一两个接口的少量操作，自建桩仍然更轻。

模拟器会不会把我的代码或请求发给 AWS？

不会。官方文档明确说明模拟器不发送请求、响应与资源数据给 AWS。默认只上报匿名的使用与错误数据，且记录里不包含请求内容、代码、凭据与个人数据，可以通过命令行参数、环境变量或配置文件关闭遥测。所有请求都打到本机 127.0.0.1:9297。

小结

AWS Emulator 的定位很清楚，它不是要做一个通用的云模拟器，而是把 AWS 官方 API 模型这一件事做对，并且用 438 个服务的覆盖面与公开的保真度测试集给自己的可靠性做背书。59.71% 的总体通过率配上 S3 与 DynamoDB 七成以上的服务级通过率，构成了一个相当可用的本地开发基座。

真正值得关注的不是它替代了多少云上测试，而是它把基础设施代码的迭代闭环搬到了本地。对需要在 CI 里跑集成测试的团队，对需要反复验证 AWS 交互的编码智能体来说，这套工具省下的是配额申请、账单与等待时间。

相关阅读

• AWS 开源 Infinity 运行时：8GB 内存塞下 75000 个智能体
• 谷歌 Agent Compute Engine：20 万智能体 500 毫秒挂起恢复
• Co-Design Bench 实测：26.4% 全对率，编码智能体还差多少
• LobeHub Agent 自改 harness：70% 通过率与 1.68 美元成本拆解