AWS 与 AutoMQ 是合作伙伴。本页只陈述有公开来源的事实：单副本 + WAL + S3 降了成本，代价落在写延迟、故障切换、版本跟进与锁定。
AutoMQ 用「单副本 + WAL + 对象存储」换来了更低的存储与跨 AZ 成本。代价落在哪里，它自己的文档里都写着。
开源 PoC 测的是 S3 WAL，商业版生产跑 EBS / FSx WAL；FSx p99 12.87 ms 来自一次短测试 S21；AWS 同规格实测 200 B 单分区 p99 7.83 ms。
官方原文：对象存储故障可「rendering AutoMQ services unavailable」；开源版只能用单 bucket S14。
同一个 Region、同样 3 个 AZ、同型号客户端、同一个压测程序和参数。数字直接取自原始结果文件。
我们在 AWS 东京区（ap-northeast-1）自己部署了 AutoMQ 1.7.4 开源版（当时最新 GA 版本），和之前 MSK 实测用的是同一个 Region、同样 3 个 AZ（apne1-az1 / az2 / az4）、同型号客户端（c7g.2xlarge）、同一个压测程序和同一组参数。开源版只有 S3 WAL，这是它唯一的写入路径。
acks=all；单分区 topic 的 leader 与客户端同在 apne1-az1。一句话结论：默认客户端参数下，AutoMQ 开源版的单分区写入在每秒 1,000 条（200 B）时还勉强跟得上（in-flight 5，p99 504.1 ms），in-flight 1 或更高速率就跟不上，积压持续增长；改用 AutoMQ 自己基准里的参数（batch.size=1MiB、linger.ms=100）后能跟上，但 p99 仍是 399.2 ms；同规格调优轮（r4，batch 512 KiB · linger 5 · zstd · in-flight 5）吞吐可到 100k msg/s，但 p50 恒 ≈ 355–365 ms、1k p99 478.5 ms（测试记录 §11.9）。MSK Standard 同为 m7g.xlarge 级、调优后 1k p99 4.58 ms（m7g.large、in-flight 1 时 5.72 ms）。
| 负载 | AutoMQ 开源版 p50 / p99 | MSK Standard p50 / p99 | AutoMQ 能否跟上设定速率 | run |
|---|---|---|---|---|
| 1,000 msg/s · linger 0 · in-flight 1 | 68 s / 112 s | 3.28 ms / 5.72 ms | 跟不上（积压增长）；发送失败 0 | 实测 |
| 1,000 msg/s · linger 0 · in-flight 5 | 373.4 ms / 504.1 ms | 11.5 ms / 17.6 ms | 跟得上；发送失败 0 | 实测 |
| 1,000 msg/s · linger 5 · in-flight 1 | 68 s / 112 s | 5.25 ms / 8.10 ms | 跟不上（积压增长）；发送失败 0 | 实测 |
| 1,000 msg/s · linger 5 · in-flight 5 | 367.4 ms / 497.0 ms | 5.34 ms / 8.27 ms | 跟得上；发送失败 0 | 实测 |
| 5,000 msg/s · linger 0 · in-flight 1 | 166 s / 207 s | 3.27 ms / 5.31 ms | 跟不上（积压增长）；发送失败 201,594 | 实测 |
| 5,000 msg/s · linger 0 · in-flight 5 | 66 s / 110 s | 11.6 ms / 16.9 ms | 跟不上（积压增长）；发送失败 0 | 实测 |
| 5,000 msg/s · linger 5 · in-flight 1 | 164 s / 207 s | 5.04 ms / 7.93 ms | 跟不上（积压增长）；发送失败 195,050 | 实测 |
| 5,000 msg/s · linger 5 · in-flight 5 | 66 s / 110 s | 5.05 ms / 7.98 ms | 跟不上（积压增长）；发送失败 0 | 实测 |
| 20,000 msg/s · linger 0 · in-flight 1 | 416 s / 766 s | 3.56 ms / 15.4 ms | 跟不上（积压增长）；发送失败 861,281 | 实测 |
| 20,000 msg/s · linger 0 · in-flight 5 | 355 s / 588 s | 11.9 ms / 17.0 ms | 跟不上（积压增长）；发送失败 0 | 实测 |
| 20,000 msg/s · linger 5 · in-flight 1 | 416 s / 786 s | 4.50 ms / 7.34 ms | 跟不上（积压增长）；发送失败 864,685 | 实测 |
| 20,000 msg/s · linger 5 · in-flight 5 | 355 s / 588 s | 4.47 ms / 6.55 ms | 跟不上（积压增长）；发送失败 0 | 实测 |
读法：「跟不上」= 实际发送速率低于设定速率，排队越积越长，延迟随测试时长线性增长；数字代表「这次 40 秒测试结束时有多糟」，不是稳态延迟。原因是机制性的：S3 WAL 每次写入要等攒批 + 一次 S3 PUT（数百毫秒），单分区吞吐上限 ≈ in-flight 数 ×
batch.size÷ 单次写入耗时；默认 16 KiB 批、in-flight 5 时 r4 实测确认上限 1,460 msg/s（73 条 / 请求 × 20 请求 / s，200 B，测试记录 §11.2）；调大批后吞吐上限显著提高，但延迟下限不变（见 9.2）。
batch.size=1MiB、linger.ms=100，公平对照）| 负载 | p50 | p99 | p99.9 | run |
|---|---|---|---|---|
| 1,000 msg/s × 200 B，1 分区 | 243.9 ms | 399.2 ms | 419.3 ms | 实测 |
| 5,000 msg/s × 200 B，1 分区 | 244.8 ms | 402.6 ms | 424.2 ms | 实测 |
| 20,000 msg/s × 200 B，1 分区 | 277.6 ms | 3.26 s | 3.48 s | 实测 |
| 10 MiB/s × 1 KiB，1 分区 | 283.4 ms | 448.2 ms | 482.2 ms | 实测 |
| 10 MiB/s × 1 KiB，12 分区 | 254.0 ms | 419.6 ms | 3.05 s | 实测 |
| 端到端（生产→消费），1,000 msg/s | 250.2 ms | 406.1 ms | 427.1 ms | 实测 |
同规格调优轮（r4，2026-11-07，m7g.xlarge，batch 512 KiB · linger 5 · zstd level 1 · in-flight 5，200 B，单分区）：1k / 10k / 50k / 100k msg/s 全部跟上，p50 / p99 分别为 351.5 / 478.5、354.5 / 484.5、357.5 / 486.5、362.5 / 496.5 ms；200k 过载（p99 2.9 s）⇒ 延迟下限 = S3 WAL 组提交间隔，客户端调不动（测试记录 §11.9）。
MSK 不需要
linger.ms=100：MSK Standard in-flight 1 · linger 0 时 p99 5.72 ms（默认 in-flight 5 时 17.6 ms，3 × m7g.large）；同规格调优轮（r4，kafka.m7g.xlarge，batch 256 KiB · zstd · in-flight 1 · linger 0）1k p99 4.58 ms。开源版在 r4 用 batch 512 KiB · linger 5 · zstd · in-flight 5，1k p99 478.5 ms（测试记录 §11.9）；它与上表 399.2 ms（linger 100）条件不同。
| acks | AutoMQ 开源版 | MSK Standard | run |
|---|---|---|---|
| acks=all | 60.1 MB/s | 87.3 MB/s | 实测 |
| acks=1 | 547.3 MB/s | 257.6 MB/s | 实测 |
照实说：
acks=1时 AutoMQ 单客户端吞吐是 MSK 的 2 倍以上。同一集群上acks=all与acks=1相差约 9 倍，而 AutoMQ 只有一份数据（RF=1）——两种 acks 理论上应当等价。按请求耗时推算，acks=1的应答早于一次 S3 WAL 写入的完成时间；AutoMQ 文档写的是「WAL 持久化后才返回」。原因本次未确认（两次运行的幂等设置也不同），建议客户在 PoC 中用acks=1+ kill -9 + 消费端对账验证是否丢数据。
acks=all，linger 5，逐秒时间线）| 事件 | AutoMQ 最坏一秒 p99 | p99 > 1 s 的秒数 | 发送失败 | MSK 对照（最坏一秒 p99） | run |
|---|---|---|---|---|---|
| 受控重启一台节点（SIGTERM，60 s 后启动） | 3.36 s | 8 秒 | 0 | 1.14 s（MSK 托管重启 broker；xlarge 另测（11-08，单分区三路审计流最坏一秒）：Standard 1.10–2.24 s、Express 2.29–2.61 s，与 large 一致（测试记录 §12.3）） | 实测 |
| kill -9 一台节点（模拟崩溃，120 s 后启动） | 12 s | 9 秒 | 0 | 未测（MSK 未做硬崩溃测试；托管重启为 1.14 s） | 实测 |
| 分区迁移（kafka-reassign-partitions） | 2.40 s | 1 秒 | 0 | 未测（MSK 迁移需要复制数据） | 实测 |
照实说：kill -9 后约 12 秒内分区被其他节点接管，不需要等故障节点重启；Apache Kafka / MSK 对 broker 硬崩溃的检测同样受 broker session 超时（默认 9 秒）约束，本次没有对 MSK 做硬崩溃测试，这一项不构成 AutoMQ 的明显劣势。分区迁移的停顿与 AutoMQ 自己公布的「最大 2.2 s」一致。「发送失败 0」不等于「零丢失」：本次没有做消费端逐条对账。
基础设施与驱动都在本项目的 lab 目录（Terraform + 同一个 Bench.java + 同一套参数）；AutoMQ 节点用官方 GitHub 发布包 automq-1.7.4_kafka-3.9.1.tgz，S3 WAL 配置按官方文档，凭证用 EC2 实例角色（authType=instance）。测试结束后全部资源已删除。
✓ 支持 · ⚠ 有前提或仅付费版 · ✗ 不支持。AutoMQ 占优的项目照实标出。
| 维度 | 项目 | Amazon MSK | AutoMQ |
|---|---|---|---|
| 部署与交付 | 交付模型 S19 | AWS 托管，ENI 接入客户 VPC | BYOC：部署在客户账号，AutoMQ 远程运维 |
| 多云 | 仅 AWS | AWS / GCP / Azure / OCI，任意 S3 兼容存储 | |
| 承诺折扣 M2 | 无 RI / Savings Plans | EC2 可用 RI / SP / Spot | |
| 延迟 | 默认写 ack p99 实测S2 | 实测 4.58 ms（调优，xlarge）/ 17.6 ms（默认，large） | 开源版「P99 600+ milliseconds」；商业版见下行 |
| 低延迟写入 S21S22 | 三种形态、所有 topic 默认毫秒级 | 仅商业版：FSx WAL p99 厂商 12.87 ms / AWS 实测 7.83 ms，需额外 FSx 费 | |
| 冷读与写入隔离 S25 | Standard 写入超过卷吞吐基线时，冷读 + 重写入实测出现过 p99 42 s | 读 S3，与写路径隔离 | |
| 可靠性 | Kafka 层副本 M20S30 | Express 固定 RF3 / minISR 2，跨 3 AZ | RF=1，没有热备 |
| 单 broker 切换 实测S25 | 实测重启最坏一秒 p99 1.14 s、0 条失败（m7g.large） | 迁移最大发送延迟 2.2 s；硬崩溃接管未公开 | |
| 对象存储故障 M7S14 | Standard 写确认不经 S3，tiered 异步上传 | S3 是写路径硬依赖；多 bucket 容灾仅商业版 | |
| SLA 纸面数字 M13S17 | Multi-AZ 99.9%，服务抵扣 | 99.95%（文本 2023-12-16，只按 produce 定义） | |
| 扩缩不搬数据 M3S25 | Standard 要搬数据；Express「up to 20x faster」 | 不搬数据，每次迁移有秒级写停顿 | |
| 版本与兼容 | Kafka 内核版本 M11S5S6 | 4.0 / 4.1；Express 另支持 4.2 | 3.9.x，Apache 已归档 |
| TV2 / ELR 实测S5 | 升到 4.1 后自动 finalize | 3.9 内核不可用（推断） | |
| KIP-932 共享组 | 实测不可用 | 不可用 | |
| 安全与合规 | IAM 认证 + 授权 M16S9 | IAM 同时负责认证和授权 | 文档未列 IAM / OAUTHBEARER |
| 客户托管密钥 M23S10 | KMS，可指定 CMK | 不支持 BYOK，建好后不能改 | |
| PCI/HIPAA/FedRAMP M8S20 | PCI、HIPAA BAA、FedRAMP Moderate / High | SOC 2、ISO 27001、GDPR；FedRAMP「align with」 | |
| 网络边界 M2S19 | 流量留在 AWS 网络内，默认不出网 | 控制台需出网；Ops Bucket 跨账号授权 | |
| 成本 | broker 间复制费 M1S13 | $0 | 无复制，改为 broker 与 S3 间流量 |
| producer 跨 AZ 费 S3 | 收费；无 key 可用 KIP-1123，有 key 无对等手段 | 约 0：需 S3WAL、3 AZ 均衡、改 client.id | |
| consumer 跨 AZ 费 M4S3 | follower fetching 降到约 0 | 读本 AZ 只读副本，需 KIP-881 | |
| 存储单价 M1S27 | EBS $0.10/GB-月每副本；tiered $0.06 | S3 $0.023 + 请求费 + 保留费 | |
| 小规模请求费 M1S27 | 不按请求计费 | 约 10 MiB/s 时 S3 请求费 $395/月 | |
| 迁移与生态 | 迁出路径 M15S11M2 | Apache segment，MM2 / Replicator 可迁出 | 自家工具只进不出；可用 MSK Replicator 全量迁出 |
| 跨产品迁入 M2S11 | Replicator 支持 AutoMQ 作源（SCRAM / mTLS） | Kafka Linking 不支持 MSK IAM 源 | |
| 入湖 M14S43 | Express Data Delivery：JSON、append | Table Topic：Upsert / CDC、Avro / Protobuf | |
| 跨 Region DR 实测M15S51 | Replicator 异步；实测同 Region 复制 p99 约 527 ms | 宣称 RPO = 0、RTO ≈ 10s，无独立验证 |
MSK 时延为 AWS 东京区实测；AutoMQ 一栏为厂商公开数字，条件不同不能直接横比；AWS 同规格实测三方对照见四方对比页（单分区 1k p99 Standard 4.58 / AutoMQ 7.83 / Express 7.96 ms）。partial = 有前提或需付费档。
vs-msk 页的算术成立，但前提有偏：MSK 没开 follower fetching，AutoMQ 一侧是约 500 ms 的 S3 WAL。按公平基线重算，节省幅度收窄，分区少时甚至反转（推导，非报价）。
上面拆的是开源版。商业版（BYOC / Software）补上了低延迟 WAL 等缺口：5 条优势如实承认；5 条七寸都附 AutoMQ 原文和可书面确认的问题。
配置页：「Choose S3 WAL or NFS WAL」，NFS 即 EFS / FSx，producer 跨 AZ 费可为 0 C-S5。
AKU 预付价约为 PAYG 标价的 1/2.7–1/4.5（推导）C-S39C-S28；1 GiB/s 时「S3 WAL + AKU + 支持」总价约 $23,676/月，低于 MSK 无法消除的 producer 跨 AZ 费约 $35,040/月（推导）
「Byte-to-byte replication … preserves partition offsets」C-S20，producer 滚动切换
商业版的低延迟来自客户账号里额外付费的一层 WAL 存储，「全托管」靠厂商运维通道和跨账号授权；建议同负载、同延迟目标、同安全基线，比总账和总风险。
形态：BYOC「deploys the AutoMQ control plane and data plane in your cloud account」，由 AutoMQ 负责部署、升级、调参、监控和应急，控制台跑在客户账号里的一台 EC2 上；Software 是「Self-managed software」，可部署在「Private data center」，由客户自己运维，计费为「Annual subscription or perpetual license」，价格 not public C-S3C-S18。AutoMQ Cloud（SaaS，部署在厂商账号）在现行文档的版本选择表里没有出现，也找不到公开的购买入口 ⇒ 【解读】在 AWS 上，「AutoMQ Cloud 全托管」实际就是 BYOC。
档位（FAQ C-S29）：Dev 20 MiB/s、2,000 分区、7 天、99.50%；Pro 1,024 MiB/s、20,000 分区、90 天、99.95%；Enterprise「Unlimited」、99.99%，可加专属支持工程师和 Multi-Region Cluster。⚠️ BYOC 限制页的数字比 FAQ 更紧，两者互相矛盾（见 K4）。
| 能力 | 档位 / 形态 | 额外成本 | MSK 对应 |
|---|---|---|---|
| EBS WAL（只覆盖单 AZ） | BYOC、Software | 每个 broker 一块小 gp3 卷 | 不需要（MSK 写路径是 3 AZ ISR） |
| EFS WAL（NFS WAL） | 只有 BYOC（Software 只有 EBSWAL / S3WAL C-S18） | EFS 存储 + 吞吐 | 不需要 |
| FSx for ONTAP WAL（NFS WAL） | 只有 BYOC；GA（2025-12） | 384 MBps 一档约 $1,216/月起（us-east-1，推导） | 不需要 |
| 零跨 AZ（ZeroZone），可与 NFS WAL 同时用 | 开源版（只有 S3 WAL）+ BYOC（S3 / NFS WAL） | 低延迟版本要付 NFS WAL 的费用 | producer 侧没有对等物；consumer 侧用 follower fetching |
| 多指标持续自平衡 | BYOC（开源版只看网络吞吐） | 含在订阅里 | Express Intelligent Rebalancing：免费，新集群默认开启 C-S61；Standard 没有内置自平衡 |
| Kafka Linking（字节级迁移，offset 原样保留） | BYOC | 迁移期双集群费用自担 | MSK Replicator（同步 offset，不是字节一致）C-S65 |
| 多 bucket 写入策略 | 商业版 | 第二个 bucket + 跨 Region 流量 | 没有对等物 |
| Multi-Region Cluster（2–3 个 Region，RPO=0，RTO≈10 s） | 只在 Enterprise 档；GA 状态 not public | not public | MSK Replicator 是异步复制，RPO > 0。MSK 没有同步方案 |
| Table Topic（Kafka → Iceberg） | 开源版和商业版都有 | Catalog 和计算费用 | MSK Streaming Tables / Data Delivery（2026-07-30 GA，只在 Express 上，功能更窄）C-S77 |
| 托管 Kafka Connect、独立 Schema Registry | BYOC | Connect 跑在客户自己的 EKS 上 | MSK Connect、Glue Schema Registry |
| 管理 UI、OpenAPI、Terraform、RBAC / SAML SSO | BYOC（开源版写「None」） | — | 官方 Terraform / CFN / CDK、IAM、IAM Identity Center |
| 静态加密 | BYOC；只能用云厂商托管密钥、只在 AWS 上、只能在创建时开启 C-S8 | — | KMS 客户托管密钥（CMK）C-S63 |
| 托管滚动升级 | BYOC（控制台升级由客户执行；Software 全部由客户执行）；数据面在线升级 5.5.6 → 5.5.7 耗时 580 s，最大确认延迟 2.9 s，0 丢（AWS 实测，测试记录 §10.2） | 支持范围不含「upgrade execution」 | AWS 执行；Express「no maintenance windows」，但仍有单 broker 重启（§0 #4） |
| 计费灵活：PAYG（经 Marketplace）、AKU 预付 1 / 12 / 24 / 36 个月、EC2 可用 RI / SP / Spot | BYOC；PAYG 只在 AWS、只有 Pro 档 C-S22 | — | MSK 没有 RI 或预付 |
| 名义 SLA 99.95%（Enterprise 99.99% 只出现在 FAQ） | BYOC | — | MSK Multi-AZ 99.9% C-S67 |
| P1 / P2 由产品研发工程师直接响应 | Production / Enterprise 支持档 | Production 档最低 $1,000/月 C-S30 | AWS Support（同样另外收费） |
| 自动扩缩 | BYOC：有定时弹性规则；按负载自动扩缩的机制没有文档 | AKU 按小时峰值计费 C-S23 | Express 由客户发起扩容；MSK Serverless 自动扩缩，但只支持 IAM、入口上限 200 MBps C-S82 |
| Kubernetes 部署模式（EKS / GKE） | BYOC；「requires a dedicated Kubernetes cluster」 C-S17 | 一套专用 EKS 集群 | 不需要：客户不运行 K8s |
【解读：怎么读这张表】低延迟 WAL、自平衡、UI、IaC、托管升级、24/7 支持，大多是在补开源版的缺口；这些 MSK 作为一方托管服务本来就有，也不另按「企业版功能」收费。真正和 MSK 拉开差距的是：producer 零跨 AZ、高吞吐 TCO 与计费灵活、Kafka Linking、多云 / 私有化、Table Topic 的功能宽度，以及只有营销页的同步 Multi-Region。静态加密和身份安全几项比 MSK 弱。
以下 5 条是事实，建议在客户面前主动讲，而不是等对方提出。
A1 · producer 侧跨 AZ 费可以降到 0，而且低延迟和零跨 AZ 可以同时拿到
client.rack）后跨 AZ 费可以降到约 0；producer 侧跨 AZ 费照收，MSK 没有对等物。KIP-1123 rack-aware partitioner 能消除无 key、未指定分区写入的跨 AZ 流量，但需要 4.4 客户端、默认关闭；有 key 的写入没有对等手段。client.id 或 automq.zone.cidr.blocks C-S5。A2 · 高吞吐时 TCO 更低
A3 · Kafka Linking：字节级复制，offset 原样保留
A4 · FSx WAL 的 p99 与 MSK Express 持平、比 Standard 高约 3 ms（同规格、各自调优）
acks=all，单分区写入确认 p50 / p99 6.64 / 7.75 ms；24 分区 1k → 50k msg/s 阶梯 p99 7.6–15.9 ms；默认客户端（zone router 开）p99 13.75 ms，AWS 实测（AutoMQ 5.5.7，测试记录 §10.12、§10.3）。（厂商公布 p99 12.87 / 13.11 / 16.30 / 17.50 ms，约 51–64 KB 消息、acks=1、厂商自测 C-S45C-S43C-S44）A5 · 多云和私有化部署
其余也应如实承认的点
| 点 | 事实 | MSK 的如实位置 |
|---|---|---|
| 持续多指标自平衡 | 默认开启，约 1 分钟收敛 C-S25 | Express IR 基本持平（免费，扩缩容「within 30 minutes」）；2025-11-20 之前建的 Express 集群默认是 Paused，要手动打开 C-S61；Standard 没有内置自平衡 |
| Table Topic 功能更宽 | Upsert / CDC、多种 Catalog C-S27 | Streaming Tables 只在 Express 上，功能更窄 C-S77 |
| EC2 可用 RI / SP / Spot | AKU 有 1 / 12 / 24 / 36 个月合约 C-S39；Spot 在 K8s 模式可用，IaaS 模式能否用 Spot：not public（见 §8.4） | MSK 不支持 Spot / RI / SP |
| 研发工程师直接响应 P1 / P2 | 要买 Production 档以上支持 C-S31 | AWS Support + 服务团队升级通道 |
| 研发活跃 | 2026-10-28 还在发版，有大公司的外部贡献者 C-S52 | 不要说「项目停滞」 |
| 经 Marketplace 采购适用 SCMP | 没有基准发布限制条款，有 45 天数据取回期 C-S42 | 适用 AWS Customer Agreement |
| 小而波动的负载 | — | MSK Serverless 是对等答案 C-S82；大而波动的负载，MSK 没有对等物 |
按「影响面 × 证据强度」排序。每条都先给 AutoMQ 自己的原文，再给可以写进 PoC 的验证方法。
s3:PutObject（用于下发许可证和版本信息）；② 基于 ngrok 的 Ops Tunnel，默认开启；③ 控制台角色在 * 上有 iam:CreatePolicy / iam:AttachRolePolicy / iam:CreateRole，没有 Condition；s3:DeleteBucket 也作用于 *；④ ToS 1.5.2 要求客户通过 IAM 授予 AutoMQ「necessary access」；⑤ K8s 模式下要「granting AutoMQ service provider access to the cluster」C-S17。s3:GetObject* 和 s3:PutObject C-S12；ClusterRoleManagementPermissions 的 Resource 是 * C-S14。s3:PutObject 限在两个前缀上 C-S12；从控制台 8.1.2 起可以自定义控制台 IAM 策略 C-S2；iam:PassRole 只限 EC2 服务；Ops Bucket「does not contain user business messages」（AutoMQ 运维授权文档）。⇒ 可以收紧，但默认状态和营销用语不一致。aws s3api get-bucket-policy --bucket <ops-bucket> 和 aws iam get-role-policy，导出全部策略；连续 24 小时开启 VPC Flow Logs 和 Route 53 Resolver 查询日志，统计出站域名（预期能看到 ngrok 相关域名）；用 IAM Access Analyzer 或 PMapper 做一次提权路径分析。判据：存在任何默认开启的入站运维通道，或存在可以提权的策略组合。acks=all，消息带序号）：FSx HA 主备切换本身影响小——多分区最大确认延迟 ≤ 6.5 s，单分区 3–7 s，0 丢；风险在首选 AZ 网络故障与 NFS 中断——FSx 首选 AZ 网络分区约 60–80 s 时多分区全集群停写 120–146 s，单分区（delivery 120 s）249 s，生产者 delivery 设为 30 s 时 3 次中 2 次永久卡死；非首选 AZ 分区 22.7–30 s；broker ↔ FSx NFS 切断 120 s 停写 149 s，没有自动隔离（hard mount）。⇒ 停写时长约为 FSx 中断时长的 2 倍（推导），且波及整个集群；全部 run 0 丢 / 0 乱序 / 0 重复。双 FSx 回退：file_system_count 2 → 1 后一台 broker 崩溃循环、控制台任务无限挂起且不报错；唯一出路是删实例重建，消息数据随之丢弃（测试记录 §11.4–§11.5）。客户 PoC 可按同样方法复测。aws s3api get-bucket-encryption 查看 KMS key 归谁；用 AWS_MSK_IAM 客户端连 AutoMQ，预期报 UnsupportedSaslMechanismException；开启 SSO 后再用本地账号登录一次，看能否进入。retention.ms「1 hour to 60 days」（FAQ 却写 Pro 90 天、Enterprise「unlimited retention」）；单实例「3AKU to 500AKU … Write Throughput: 60MBps~10000MBps」（FAQ 却写 Enterprise「Unlimited ingress」）；offsets.retention.minutes 固定为 7 天，「Customization not supported」C-S4C-S29。linger.ms=0）的客户。retention.ms，统计超过 4 MB/s 和超过 60 天的 topic 数；用真实客户端配置压测，看请求数会让 AKU 数涨到多少（中档算例里，按请求数需要 13 个 AKU，按吞吐只需要 8 个，推导）。acks=all 单分区 p99 7.75 ms，AWS 实测（AutoMQ 5.5.7，测试记录 §10.12）），但仍没有生产案例，尾延迟与故障行为要单独看（见下方实测结论与 K2）。client.id 都标成同一个 AZ（automq_az=us-east-1b），acks=1 C-S43。acks=1 加 RF1 由 AutoMQ 的架构决定（副本由存储层承担），这一项本身合理。acks=all，单分区 1k–20k msg/s p99 7.64–7.93 ms，50k msg/s 时 11.35 ms，100k 过载（以上为推荐客户端、默认 16 KiB 批；50k 是默认批的临界点、两轮不一致：§10.12 p99 11.35 ms 达标，r4 重建实例 42.75 ms 未达标；batch 256 KiB + zstd 后 200k msg/s p99 8.66 ms，1 h 浸泡 p99.99 33.75 / max 88.82 ms，测试记录 §11.9）；多分区 p99 7.6–15.9 ms；单分区 4 h 浸泡（20k msg/s，2.88 亿条）p99 / p99.99 / max 为 7.87 / 32.65 / 235.6 ms，有 3 s 超过 100 ms；多分区 2 h 浸泡 p99.99 / max 55.85 / 238.7 ms ⇒ 小消息下 FSx 的 p99 低于厂商公布的 12.87 ms。仍需 PoC：24 小时并经过一次 FSx 维护窗口、EFS WAL（判据：EFS WAL 的 p99 超过 20 ms）。按客户场景使用；只有当客户把对应能力当作选型理由时才需要展开。
| 场景 | 问题 | 事实 | 建议客户问 AutoMQ | MSK 侧（如实） |
|---|---|---|---|---|
| 客户把跨 Region RPO=0 当选型理由 | Multi-Region 只有营销页 | BYOC 文档（113 页）里没有这一页；页面上的「Read Documentation」链接指向文档首页 C-S37；只在 Enterprise 档；「The Only Multi-Region Kafka with RPO = 0」与 Redpanda 2026-08-11 宣布 Stretch Clusters GA、RPO=0 的说法冲突 C-S51；「eliminating expensive cross-region traffic」也不成立：第二个 Region 的 bucket 同样要写一份，跨 Region 字节照样计费（S3 跨 Region 传出 $0.02/GB 起 C-S75） | 「Multi-Region 的文档、GA 日期、两个 Region 之间同步写的 produce p99、价格，以及一个公开客户，能书面提供吗？」 | MSK Replicator 是异步复制，RPO > 0。如实承认，再讨论代价（延迟）与文档 |
| 客户看重 SLA 数字 | SLA 赔付范围窄 | 正式文本只承诺 99.95%（「Last updated: December 16, 2023」）；只有写入失败超过 1 分钟才算不可用；赔付基数是「Monthly Service Fee … for a single AutoMQ instance」，只赔代金券 C-S32；BYOC 下客户付给 AWS 的 EC2 / S3 / FSx 不在赔付基数里；扩容可用性划给客户：「Responsible (ensure cloud resource availability)」 | 「SLA 的赔付基数包不包括我们付给 AWS 的部分？读不可用算不算不可用？99.99% 写在哪份合同里？」 | MSK SLA 也只给 Service Credit，并排除「caused by the underlying Apache Kafka … engine software」的故障 C-S67 ⇒ 不要说「MSK SLA 赔得更多」 |
| 客户以为「全托管」= 零运维 | 控制台是客户账号里的单台 EC2 + Docker | 「upgrading the version only requires updating the Docker image」；「Do not delete or clear the host directory」C-S13；7.x→8.x「only AWS environments」C-S14；资源清单里的默认 AMI 是 Amazon Linux 2 C-S15，而 AL2 已于 2026-06-30 结束支持 C-S70。8.x Docker 化之后宿主机 OS 由谁选：not public | 「控制台 EC2 宕机时，数据面、扩缩容、告警、运维隧道还能不能用？元数据目录谁来备份？宿主机 OS 谁来打补丁？」 | 控制面在 AWS 一侧，客户不需要运维 |
| 已在用 Kafka 4.x 客户端或 KIP-848 | Kafka 3.9 天花板，升级节奏不透明 | 商业版兼容范围「8.3.1 | 1.0.0 ~ 5.5.x | 0.9.0.x ~ 3.9.x」，往前 4 个控制台版本都停在 3.9.x C-S2；Apache Kafka 4.0.0 已发布 19 个月，兼容性页仍写「It supports the latest updates to Apache Kafka versions within T+1 month」C-S79；release notes 全部没有日期，没有公开的版本 EOL 政策；7.x→8.x 升级要把环境信息发给 AutoMQ，由「AutoMQ technical personnel」生成升级命令 C-S14 | 「KIP-848 新消费组协议、Kafka 4.x 客户端什么时候能用？『T+1 month』从哪个版本开始算？请给出版本 EOL 表，以及大版本升级中需要厂商人工介入的步骤和排期。」 | ⚠️ MSK 自己也把 3.9.x 标为「(Recommended)」；4.2 只在 Express 上 C-S66 ⇒ 只对已在用 4.x 或 KIP-848 的客户有影响 |
| 关心退出成本 | Kafka Linking 只能迁入，不能迁出 | 「supports only AutoMQ instances as Sink Clusters」；「does not support MSK IAM Role authentication mode」C-S20；「reserve an additional 50% capacity」；「it is still necessary to restart the client application」C-S21；终止后数据取回期：官网 ToS 30 天、SCMP 45 天 | 「三年后要迁出，AutoMQ 提供什么工具？offset 怎么对齐？订阅或预付许可证到期后，集群是只读、停写还是有宽限期？bucket 里由商业数据面 5.x 写入的数据，能否直接用开源版读出？」（后两项 not public） | 迁出可以用 MSK Replicator（支持自管 Kafka 作源）或 MM2，只是 offset 不是字节一致 ⇒ 不要说「迁进去就出不来」 |
| 受监管行业 / 政府 / 中国区 | SOC 2 系统边界不公开；没有 GovCloud 和中国区 | 「A Type II report covering controls relevant to security, availability, and confidentiality」，没有写覆盖哪个系统 C-S34；报告要在 Trust Center 申请 C-S71；BYOC 支持的 30 个 AWS Region 里没有 us-gov-* 和 cn-* C-S4 |
「SOC 2 的 system description 覆盖运维通道和读取 Ops Bucket 的那个系统吗？诊断数据存放在哪个 Region？这些 Region 的交付形态是什么？」 | MSK 合规页：「These include PCI and HIPAA BAA」C-S80；MSK 在 AWS FedRAMP 服务范围页上 C-S81；AWS SOC 报告可在 AWS Artifact 下载 |
| 客户把多云当选型理由 | 「多云同一套技术栈」，但各云能力不一致 | NFS WAL（EFS / FSx）只在 AWS；Regional EBS WAL 只在 Azure / GCP / 阿里云；Software 只有 EBSWAL / S3WAL C-S18；PAYG、静态加密、控制台 7.x→8.x 升级都只支持 AWS C-S22C-S8C-S14；K8s 模式在各云允许的机型各只有几种 C-S17 | 「同一份延迟、加密和计费口径在每朵云上都成立吗？请按云列出 WAL 类型、p99、加密方式和计费方式。」 | MSK 只在 AWS，不和多云比 |
| 流量波动大 / 想用 Spot | 自动扩缩与 Spot 的机制和责任边界未写清 | 公开文档只有定时弹性规则，按负载自动扩缩的触发机制 not public；在线扩缩 3 ↔ 6 broker 最大确认延迟 0.1–0.3 s、0 丢，AWS 实测（AutoMQ 5.5.7，测试记录 §9.16、§10.9、§10.13））（厂商基准 0→1 GiB/s 扩容约 4 分钟）；BYOC IaaS 模式没有 Spot 配置项（能否用 Spot：not public）；FAQ 已改为「Teams should still set conservative Spot policies and validate availability targets」C-S29；SLA 把「ensure cloud resource availability」划给客户 C-S32 | 「扩容的触发指标是什么？AKU 额度不够或 EC2 没库存时会怎样？扩出来的容量怎么计费？Spot 回收导致容量不足，SLA 算谁的？」 | MSK 不支持 Spot，如实承认；小而波动的负载可以介绍 MSK Serverless C-S82 |
| 依赖 IaC 交付 | Terraform 尚未 1.0，只管已有环境 | provider ~> 0.4.4；只能「manage resources in an existing AutoMQ BYOC environment」；需要控制台 8.3.6 / 8.3.8，而公开 release notes 最高只写到 8.3.1 C-S38C-S2 |
「环境本身怎么用 IaC 创建？provider 依赖的控制台版本何时公开？」 | 官方 Terraform / CFN / CDK |
| 需要统一可观测 / 审计 | 客户自备监控栈；审计范围不清 | 支持 Prometheus Remote Write、CloudWatch、Datadog 等，但「does not offer managed Grafana dashboard services」；审计只找到 Ops Tunnel 会话审计，控制台操作审计的范围 not public | 「控制台上的人员操作有没有审计日志？保留多久、能否导出？」 | CloudWatch 指标、Open Monitoring（Prometheus） |
| 经常扩缩或重平衡 | 扩缩时的迁移尖刺已降到亚秒级；自平衡迁移每 600 s 一次 0.97–1.87 s | 在线扩缩 3 ↔ 6 broker 最大确认延迟 0.1–0.3 s，无零确认秒，0 丢，AWS 实测（AutoMQ 5.5.7，测试记录 §9.16、§10.9）；5.5.6 时参与均衡的 topic 每次迁移约 1–1.5 s 单秒尖刺（测试记录 §9.16）（厂商基准「Maximum send latency of 2.2s」C-S26）；慢节点隔离的检测机制 not public | 「持续自平衡触发的迁移，producer 的 p99.9 和最大延迟是否与扩缩时一致？」 | MSK 滚动重启同样有秒级尖刺（实测最坏一秒 p99：Standard 1.14 s、Express 1.34 s 实测），如实承认；Express 扩缩由 IR 搬迁；自平衡（auto balancer）照常运行时每 600 s 迁移 leader，单次停顿 0.97–1.87 s，5.5.7 仍存在，订单 topic 须排除，AWS 实测（测试记录 §6.9、§10.9） |
| 维度 | S3 WAL（对照） | EBS WAL | EFS WAL | FSx for ONTAP WAL |
|---|---|---|---|---|
| 可用性 | 开源版唯一选项；BYOC、Software 都有 | BYOC、Software | 只有 BYOC；文档没有标 preview | 只有 BYOC；GA（2025-12） |
| produce p99（公开 / 实测） | 823 ms（1 GiB/s 基准）；开源对比表写「P99 600+ milliseconds」 | not public（只公布均值「Less than 3ms」，场景是追读） | not public（计算器上的「~10ms」只是档位标签） | AWS 实测（200 B、acks=all）：单分区 p99 7.75 ms（§10.12）/ 7.83 ms（r4 调优，1k）、1k–200k ≤ 9.10 ms，多分区 7.6–15.9 ms（AutoMQ 5.5.7，测试记录 §10.12、§10.3、§11.9）⇒ 小消息、中低速率下 p99 可低于 10 ms。（厂商公布 12.87 ms C-S45；13.11 ms（linger.ms=0）、16.30 ms（linger.ms=3）C-S43；17.50 ms C-S44，约 51–64 KB、acks=1） |
| 介质延迟（AWS 文档） | — | — | Regional 模式约 2.7 ms，注明「best-case performance under optimal conditions」C-S57 | 「sub-millisecond file operation latencies」C-S55 |
| 写入跨几个 AZ | 多个（S3 Standard） | 1 个 | 多个（Regional） | 2 个（一个 HA 对） |
| 耐久性（AWS 原文） | 11 个 9 | gp3「99.8% - 99.9% durability」；io2 99.999% C-S59。⚠️ AutoMQ 文档写「Between 5 nines and 9 nines」C-S7，写高了 | 跨「multiple geographically separated Availability Zones」冗余存储 | 同步复制到另一个 AZ 的 standby |
| 整个 AZ 故障时 | 不受影响 | 该 AZ 内未上传的 WAL「stuck until the AZ recovers」（Fresha C-S50）；RPO > 0，窗口大小 not public | 其他 broker 挂载同一路径接着回放；按 AWS 的设计 RPO = 0；RTO not public | 若故障的是 FSx 首选（active）AZ：以网络分区模拟约 60–80 s，多分区全集群停写 120–146 s，单分区 249 s；broker 下线叠加该 AZ 子网切断（AWS FIS 近似注入，11-08）：三个 AZ 的生产者全停 369–376 s、每路 ≈ 30 万笔失败、0 丢（测试记录 §12.3）；非首选 AZ 分区 22.7–30 s；FSx HA 主备切换本身最大确认延迟 ≤ 6.5 s，AWS 实测（AutoMQ 5.5.7，测试记录 §10.5、§10.8、§10.9、§10.13））（AWS 文档：切换「typically … less than 60 seconds」C-S53）；同步复制，RPO = 0（实测 0 丢） |
| 例行维护 | — | EBS 没有维护窗口 | AWS 托管，没有公开的维护窗口 | 每「several weeks」打一次补丁，每 14 天内至少一个维护窗口；每次补丁可能带来两次不到 60 s 的 I/O 暂停 C-S54；调整吞吐也会触发一次切走和切回；经 AutoMQ 控制台换档（384 → 768）不原地改吞吐，而是新建一套 FSx 并两轮滚动重启，实测耗时 52.7–53.9 min，期间尖刺 ≤ 3.1 s（AWS 实测，AutoMQ 5.5.6 / 5.5.7，测试记录 §7.12、§10.9） |
| 额外的 AWS 账单项 | S3 请求费（比其他 WAL 高） | 每个 broker 一块小 gp3 卷 | EFS 存储 + Provisioned 吞吐（或 Elastic 模式按写入字节计费） | 吞吐容量 + SSD 容量 + 超出免费额度的 IOPS |
| 零跨 AZ 是否成立 | ✅ | ❌（不在零跨 AZ 支持的 WAL 列表里） | ✅（前提是 broker 挂本 AZ 的挂载点；从其他 AZ 访问挂载点收 $0.01/GB） | ✅（2022-02-23 之后创建的 Multi-AZ 文件系统跨 AZ 访问不收费）；不在 active 所在 AZ 的 broker 写 WAL 要多跨一个 AZ |
| 建好后能否换 WAL 类型 | 没有文档说可以；唯一公开证据是 Fresha 的原话「would require yet another migration」C-S50 ⇒ 无法核实，放进 PoC | 同左 | 同左；控制台 8.3.1 起只能调吞吐规格 | 同左 |
| MSK 的对应物 | 不需要 | 不需要（写路径是 broker 本地存储 + 3 AZ ISR） | 不需要 | 不需要 |
【解读】三种低延迟 WAL 的风险各不相同：EBS 的问题是数据会不会丢（耐久性）；FSx 的问题是停多久、多久停一次、一停影响多大范围（共享组件的可用性；实测切换本身 ≤ 6.5 s，首选 AZ 网络故障时全集群停写 120–146 s，见 K2）；EFS 的问题是够不够快、吞吐和 IOPS 上不上得去（延迟和配额）。MSK 用同一套 ISR 机制同时覆盖这三方面。
额外成本 vs 它省掉的 producer 跨 AZ 费（us-east-1 公开价 C-S56C-S58，推导）
单价：FSx ONTAP Multi-AZ 第二代吞吐容量 $2.500/MBps-月，SSD $0.250/GB-月；EFS Provisioned 吞吐 $6.00/MiBps-月，Elastic 模式写入 $0.06/GB；同 Region 跨 AZ 每个方向 $0.01/GB。假设 3 AZ 均衡，不开零跨 AZ 时 2/3 的 produce 流量跨 AZ，每月 730 小时 ⇒ producer 跨 AZ 费约 $34.22 / MiB/s-月。
| 平均写入 | 省掉的 producer 跨 AZ 费/月 | FSx（第二代 Multi-AZ，1,024 GiB SSD） | EFS Provisioned | EFS Elastic |
|---|---|---|---|---|
| 10 MiB/s | $342 | 384 档：$1,216（比它省掉的钱还多） | $60（计算器实际配置 58 MiB/s，即 $348） | $1,540 |
| 100 MiB/s | $3,422 | 384 档：$1,216 | $600 | $15,398 |
| 600 MiB/s | $20,531 | 1,536 档：$4,096 | $3,600（注意单个文件系统 25,000 写 IOPS 上限） | $92,391 |
| 1 GiB/s | $35,040 | 2 套 1,536 档：$8,192 | $6,144 | $157,680 |
推导举例：384 档 = 384 × $2.5 + 1,024 × $0.25 = $1,216。AutoMQ 博客说 1 GBps 场景 FSx「adds approximately USD 8,000」，与 2 × 1,536 档的 $8,192 吻合。
读法与必须承认的点：
acks=all，同规格、各自调优，r4）为 7.83 ms，与 MSK Express 7.96 ms 持平，高于 MSK Standard 4.58 ms（AWS 实测，AutoMQ 5.5.7，测试记录 §11.9）；多分区 7.6–15.9 ms（测试记录 §10.3）。调优前一轮 MSK Standard（m7g.large）默认 in-flight 5 时 17.6 ms 实测、in-flight 1 时 5.72 ms 实测。（厂商公布 12.87 ms）PoC 判据（交给 SA）
| 优先级 | 测什么 | 怎么测 | 判据（满足即说明问题成立） |
|---|---|---|---|
| P0 | FSx 切换期间 produce 停了多久 | BYOC + FSx WAL，3 AZ，50 MiB/s，acks=all，消息带序号；在 FSx 上修改吞吐容量触发切换 |
任一 producer 连续写失败或写延迟超过 5 s；或所有 broker 同时出现延迟尖刺。AWS 实测：FSx HA 切换最大确认 ≤ 6.5 s（未触发）；FSx 首选 AZ 网络分区时全集群停写 120–146 s（触发）（AutoMQ 5.5.7，测试记录 §10.5、§10.9） |
| P0 | 同负载下的 p50 / p99 / p99.9 | 200 B 和 1 KB；EFS WAL、FSx WAL、MSK 三套同时跑 | EFS 的 p99 超过 20 ms；或小消息下 FSx 的 p99 明显高于 12.87 ms。AWS 实测（1 KiB × 5k msg/s：p50 6.39 / p99 11.65 ms，测试记录 §10.11）：200 B 下 FSx p99 单分区 7.75 ms、多分区 7.6–15.9 ms（未触发）（AutoMQ 5.5.7，测试记录 §10.12、§10.3）；1 KB 与 EFS 未测 |
| P0 | EBS WAL 隔离一个 AZ | 用 NACL 把一个 AZ 的 broker 子网隔离 15 分钟 | 恢复后序号有缺口（丢数据），或某些分区超过 60 s 不可写 |
| P1 | FSx 写吞吐能否长期达标 | 384 档持续写 150 MiB/s，跑 24 小时，期间经过一次维护窗口。AWS 原文「Generally … up to a third of the provisioned throughput capacity for writes」C-S55，只作判据，不作结论 | 吞吐达不到标称值，或 p99 随时间变差。AWS 实测（短时阶梯）：384 档可用写吞吐约 170–200 MiB/s，250 MiB/s 时 p99 154.5 ms；768 档 300 MiB/s 时 p99 22.6 ms（AutoMQ 5.5.6 / 5.5.7，测试记录 §6.6、§6.14、§10.3）；24 小时长跑未测 |
| P1 | 实际跨 AZ 字节数 | VPC Flow Logs 按 AZ 统计 broker 到 FSx / EFS ENI 的流量 | broker 访问了其他 AZ 的 EFS 挂载点（产生 $0.01/GB） |
| P2 | WAL 类型能否更改 | 在控制台上尝试，同时书面询问厂商 | 必须重建集群并再迁移一次 |
| P2 | 控制台故障影响什么 | 停掉控制台 EC2 30 分钟 | 扩缩容、告警或运维隧道失效（目前 not public） |
费用构成
| 费用项 | 收费方 | 是否计入 AutoMQ 计算器 | 证据 |
|---|---|---|---|
| 订阅：PAYG | AutoMQ，经 AWS Marketplace 收取 | ✅ | Data Ingress $0.02→$0.008/GiB，Egress $0.0067→$0.00275/GiB，Retention $0.01→$0.005/GiB-月，阶梯自动打折；Cluster Uptime $0.411/h；按压缩后字节计量 C-S28。Marketplace 上只有一个计价维度：「Each unit is 1 cent of usage」C-S41 |
| 订阅：AKU 预付 | AutoMQ | ❌（计算器给的是 PAYG 价） | 「Each AKU provides 30 MiB/s write throughput or 60MiB/s read throughput … $146.00」C-S39；写 AKU 和读 AKU 相加；每 AKU 还限 800 req/s 和 1,125 个分区，按小时峰值计费 C-S23；1 / 12 / 24 / 36 个月合约，长约单价 not public |
| EC2、EBS、S3 存储与请求 | AWS（客户账号） | ✅ | — |
| EFS / FSx WAL | AWS | ✅（EFS 按 Provisioned 计；FSx 按固定档计，最低一档 $1,228.56/月） | 计算器 C-S28；单价 C-S56C-S58 |
| 控制台 EC2、第二个（运维）bucket、NAT、VPC Endpoint、CloudWatch | AWS | ❌ | 「At least 1 VM is consumed to deploy the management interface」；「Two buckets per environment」 |
| AutoMQ 支持费 | AutoMQ | ❌ | Production 档「$1,000 per month, minimum」，月账单首 $50K 按 10%、次 $50K 按 8%、再往上 $900K 按 6%、超过 $1M 的部分按 3%；「Product subscription billed separately」C-S30 |
| AWS Support 随之上涨的部分 | AWS | ❌ | BYOC 下的 EC2 / S3 / FSx 都计入 AWS 账单，AWS Support 按账单百分比收费 ⇒ BYOC 客户要付两份支持费 |
| producer / consumer 跨 AZ | AWS | 计为 $0 | 前提是零跨 AZ 生效：3 AZ、各 AZ 客户端均衡、客户端配置正确 |
三档 TCO（USD/月，推导，不是报价）
统一假设：us-east-1，每月 730 小时，On-Demand 标价；3 AZ；扇出 2（读 = 2 × 写）；保留 72 小时；峰值 = 平均值。MSK 两边都开 follower fetching；producer 跨 AZ 费 = 2/3 × 写入量 × $0.02/GiB C-S68。AutoMQ 一侧直接用 AutoMQ 官网计算器 2026-10-29 的结果，未作改动 C-S28，不含上表标 ❌ 的项。每月 GiB 数：小档 25,664，中档 256,641，大档 2,628,000。MSK 配置：小档 3 × express.m7g.large 或 3 × kafka.m7g.large；中档 3 × express.m7g.2xlarge 或 6 × kafka.m7g.2xlarge；大档 3 × express.m7g.16xlarge 或 12 × kafka.m7g.4xlarge（按分区数和吞吐护栏配齐）。
| 方案 | 小 10 MiB/s | 中 100 MiB/s | 大 1 GiB/s | 推导 / 构成 |
|---|---|---|---|---|
| MSK Standard + tiered + FF | ≈ $1,020 | ≈ $9,306 | ≈ $73,372 | 中档：broker $3,574 + 本地 EBS $791 + tiered $1,519 + producer 跨 AZ $3,422（256,641 × 2/3 × $0.02）。大档另加预置存储吞吐 $384 |
| MSK Express + FF | ≈ $1,745 | ≈ $12,094 | ≈ $115,833 | 中档：broker $3,574 + 写入费 $2,566 + 存储 $2,531 + producer 跨 AZ $3,422 |
| AutoMQ S3 WAL（约 500 ms） | $1,724 | $9,007 | $58,914 | 计算器原值（中档：AWS 部分 $1,530 + AutoMQ $7,477） |
| AutoMQ EBS WAL（约 10 ms，只覆盖单 AZ） | $1,351 | $8,434 | $55,697 | 计算器原值 |
| AutoMQ EFS WAL（约 10 ms，多 AZ） | $1,544 | $10,027 | $72,160 | 计算器原值（Provisioned 模式） |
| AutoMQ FSxN WAL（约 10 ms，多 AZ） | $2,575 | $9,707 | $64,546 | 计算器原值 |
| + AutoMQ Production 支持费（按 PAYG 费计） | +$1,000 | +$1,000 | +$4,648 | max($1,000, 10% × AutoMQ 费)；三档 AutoMQ 费分别是 $1,182、$7,477、$46,479 |
| AutoMQ S3 WAL，按 AKU 价 + 支持 | $1,980 | $4,428 | $23,676 | 大档：AWS $12,434 + 70 AKU × $146 = $10,220 + 支持 $1,022 |
| AutoMQ FSxN WAL，按 AKU 价 + 支持 | $2,830 | $5,128 | $29,309 | 中档：AWS $2,230 + 13 AKU × $146 = $1,898 + 支持 $1,000 |
| 对比（推导） | 小 | 中 | 大 |
|---|---|---|---|
| AutoMQ FSxN（PAYG + 支持）vs MSK Express（两边都是低延迟、多 AZ） | AutoMQ 贵 105% | AutoMQ 便宜 11% | AutoMQ 便宜 40% |
| AutoMQ S3 WAL（PAYG + 支持）vs MSK Standard + tiered | AutoMQ 贵 167% | AutoMQ 贵 8% | AutoMQ 便宜 13% |
| AutoMQ FSxN（AKU + 支持）vs MSK Standard + tiered | AutoMQ 贵 177% | AutoMQ 便宜 45% | AutoMQ 便宜 60% |
读法：
合同：两条采购路径适用不同条款
| 条款 | 官网 ToS（2025-12）C-S33 | Marketplace EULA = SCMP（2023-11-07）C-S42 | MSK |
|---|---|---|---|
| 发布基准 | 1.4(g) 禁止「publish benchmarks」 | 没有限制条款 | AWS Service Terms 允许，条件是附上复现信息 |
| 受监管数据 | 1.4(l) Prohibited Data 包括 PHI / PCI / GLBA 数据 | 只禁止「High Risk Activities」 | PCI、HIPAA BAA C-S80、FedRAMP C-S81 |
| 总责任上限 | 「TOTAL CASH PROCEEDS ACTUALLY RECEIVED」，没有时间窗口 | 前 12 个月已付和应付的费用；SaaS 安全事件上限是 3 倍 | — |
| 调价 | 6.3「may be modified by AutoMQ from time to time」；另有一条规定条款修改「upon renewal」才生效 | 合约期内价格锁定 | 按 AWS 定价页 |
| BYOC 客户义务 | 1.5.2 通过 IAM 授权；1.5.3 客户对自己云资源导致的中断负责；1.5.4 改硬件、网络或 OS 要提前 48 小时书面通知 | 没有对应条款 | 补丁和升级由 AWS 执行 |
| 终止后取回数据 | 30 天 | 45 天 | — |
⇒ 对客户的正确问法：「你们走 Marketplace 采购，适用的是 SCMP 还是官网 ToS？请法务书面确认以哪份为准。」⚠️ 「AutoMQ 合同禁止发布基准」「商业版 PoC 结果不能对外发」只对签了官网 ToS 的客户成立，不能一概而论。
SLA C-S32：正式文本只有 99.95%，「Last updated: December 16, 2023」；只有写入失败持续 1 分钟以上才算不可用；赔付基数只算付给 AutoMQ 的费用，且「limited to vouchers」；BYOC 下云资源可用性由客户共同负责（「Responsible (ensure cloud resource availability)」）。推导：大档 S3 WAL 总成本 $58,914，其中付给 AutoMQ 的是 $46,479；即使最差一档全额赔付，也只能拿到 $46,479 的代金券，付给 AWS 的 $12,434 不赔，业务损失更不赔。MSK SLA 同样只给 Service Credit C-S67。
| 档位 | 价格 | P1 首次人工响应 |
|---|---|---|
| Free | $0，不含技术支持 | — |
| Dev | 「5% of monthly charges, with a $29 minimum」 | 8 个支持时段小时 |
| Production | 最低 $1,000/月，按阶梯比例收取 | 1 小时，24/7 |
| Enterprise | Custom pricing | 30 分钟，24/7 |
其他商务点：
截至 2026-10-29 仍为 not public（不能当结论用）：Multi-Region 的 GA 状态、延迟和价格；EFS WAL 的任何延迟实测；控制台 EC2 宕机会影响什么；WAL 类型能否更改；慢节点隔离的检测指标；SOC 2 的系统边界；Software 版价格；AKU 长约单价；预付许可证到期后集群的行为；Kafka 4.x 支持时间表；SaaS 是否在售；按负载自动扩缩的触发机制；BYOC IaaS 模式能否用 Spot；版本 EOL 表与各版本发布日期；商业数据面写入的 bucket 能否被开源版直接读取；控制台操作审计的范围。
两种架构各有适合的负载。下面是诚实的划分。
AWS_MSK_IAM，或要求 IAM policy 级授权、KMS CMK按「对典型客户的影响 × 依据强度」排序。每一条都给出机制、原文出处、影响谁，以及你可以在 PoC 里自己验证的方法。
AWS 与 AutoMQ 是合作伙伴（AWS Storage Blog 联合文章 S21、AWS Marketplace 上架 S46）。本节只陈述有公开来源的事实，给出原文引文与来源，并列出客户在选型前应当向 AutoMQ 确认的问题。
| 排名 | 不足 | 适用的 AutoMQ 形态 | 影响 | 依据强度 |
|---|---|---|---|---|
| 1 | 开源版只有 S3 WAL，官方写写入 P99「600+ milliseconds」；低延迟 WAL 全部闭源 | 开源版 | 高 | 官方原文 |
| 2 | 自研存储引擎 2026 年修过两类数据丢失 / 损坏缺陷，修复不会修复已经损坏的对象；#3686 里维护者给的恢复方案是删除过期段中的 offset / 消费组元数据 | 全部 | 高 | 官方原文 |
| 3 | 内核停在 Kafka 3.9：下一个大版本的 1.8 分支仍是 3.9.2，Apache 已把 3.9.x 归档，与文档写的「T+1 month」不符 |
全部 | 中–高 | 官方原文 |
| 4 | Kafka 层单副本（RF=1）、没有热备：受控重启有秒级写停顿；商业版 FSx WAL 实测 kill -9 单 broker 停写 15–27 s | 全部 | 高 | 官方原文 + AWS 实测 |
| 5 | 认证文档没有列 IAM / OAUTHBEARER；Kafka Linking 不支持 MSK IAM | BYOC（文档） | 中 | 官方原文 |
| 6 | 静态加密不支持 BYOK，只支持 AWS，建好后不能再开 | BYOC（文档） | 中（受监管行业为高） | 官方原文 |
| 7 | 小规模时，S3 请求费抵掉了它省下的 producer 跨 AZ 费（用 AutoMQ 自己计算器的数字） | S3 WAL | 中 | 按官方计算器推算 |
| 8 | S3 是写路径的硬依赖；开源版只能用单 bucket，多 bucket 只在商业版 | 全部（开源最重） | 中 | 官方原文 |
| 9 | EBS WAL 只在单 AZ，而且 AutoMQ 文档写的耐久性（5–9 个 9）高于 AWS 对 gp3 公布的 99.8–99.9% | 商业版 EBS WAL | 中 | 官方原文 |
| 10 | BYOC 营销写「零网络连接」，与它自己的安装 / 运维文档矛盾 | BYOC | 中 | 官方原文 |
| 11 | AutoMQ Cloud 文档的硬限制：单分区读、写各 4 MBps，offsets 固定保留 7 天，保留期不超过 60 天（BYOC 实测单分区写：默认客户端批约 10 MB/s；batch 256 KiB + zstd 后 200k msg/s × 200 B 达标） | AutoMQ Cloud 文档范围 | 中 | 官方原文 + AWS 实测 |
| 12 | 迁移工具只进不出；S3 上是私有格式，迁出要全量复制 | 全部 | 中 | 官方原文 |
| 13 | 默认条款禁止发布基准，禁止 PHI / PCI / GLBA 数据；两份用户协议同时在线 | 商业版 | 中（采购问题） | 官方原文 |
| 14 | 「零跨 AZ」有前提：S3WAL（按文档）、3 AZ、各 AZ 产消均衡、改 client.id 或配 CIDR |
全部 | 中 | 官方原文 |
| 15 | KRaft controller 同时存 S3 对象元数据：有规模风险（#3477 修复后没有复测） | 全部 | 中 | 单一来源 |
| 16 | ZeroZone（零跨 AZ）路径的正确性缺陷：1.7.4 上存在，1.7.5 RC 在修；IPv6 仍 open | 全部 | 中 | 单一来源 |
| 17 | S3 SDK 传输层问题在 1.7 上要手工配置规避，修复在未发布的 1.8 | 开源 1.7.x | 中 | 单一来源 |
| 18 | WAL 类型是集群级配置，换延迟档要再迁一次 | 全部 | 中 | 单一来源 |
| 19 | 文档里的物理参数有错（gp3 写成 $0.20 ⇒ 声称省「26×」） | — | 低 | 官方原文 |
| 20 | 报告 CRITICAL CVE 的 issue（#3617）截至 2026-10-29 仍 open（38 天） | 发布镜像 | 低 | 官方原文 |
| 21 | 「sub-10ms P99」有前提：实测推荐客户端参数下单分区 p99 7.75 ms 成立；默认客户端（zone router 开，24 分区 100 B）13.75 ms、多分区高速率最高 15.9 ms | 营销口径 | 低 | AWS 实测 |
另有 11 条（#22–#32）影响较低或只适合作为采购问题，见本节末尾的紧凑表。
每张卡片包括：是什么 / 依据 / 影响谁 / MSK 的做法 / 如何在 PoC 中自己验证。验证实验建议在独立测试账号中进行，不碰生产资源。AutoMQ 开源版是 Apache 2.0，测试结果不受限制；商业版试用的结果受 AutoMQ ToS 1.4(g)「publish benchmarks or performance information」约束 S15，仅用于内部评估。
batchInterval=250 milliseconds and maxBytesInBatch=8388608 bytes」S12），再加一次 S3 PUT。块存储 / 文件存储 WAL（EBS、EFS、FSx）不在开源仓库里。linger.ms=100）：produce P50 465 / P99 823 / P999 1,049 ms；E2E P99 1,189 ms S23。acks=all，客户端与 leader 同 AZ）：
acks=all）：推荐客户端（in-flight 5、linger 1、关 zone router）p50 6.64 / p99 7.75 ms；MSK Standard in-flight 1 为 5.72 ms、默认 in-flight 5 为 17.6 ms；AutoMQ 默认客户端（zone router 开）p99 13.75 ms（测试记录 §10.3、§10.12）。同规格、同判据的对照见下行（r4）。（厂商公布 12.87 ms，测试条件为约 51 KiB 大消息、5 s 短测。）「MSK 比 AutoMQ 低一个数量级」只对 S3 WAL 成立。acks=all，三家同为 m7g.xlarge 级、各自由同一判据选出的最优客户端配置；AWS 实测，测试记录 §11）：写入确认 p99 MSK Standard 4.58 ms、AutoMQ 商业版 + FSx WAL 7.83 ms、MSK Express 7.96 ms；p50 分别为 3.29 / 6.71 / 4.21 ms。acks=all、linger 0，in-flight 1 和 5 各一组），再加一组 10 MiB/s × 1 KB、linger 5。记 produce p50 / p99 / p99.9 和 E2E p99，同 AZ 与远 AZ 的 consumer 分开记。预期：produce p99 在 250–900 ms；MSK 同负载 5.7–17.6 ms（3 × m7g.large，in-flight 1 / 5），调优后 4.6–8.0 ms（r4，xlarge 级：Standard 4.58、Express 7.96 ms）。判据：AutoMQ 开源版 p99 低于 100 ms，则这一条不成立。__consumer_offsets 报「Invalid footer magic: -1」，消费组回到 earliest。维护者原话：修复「does not repair existing objects」，读到的「may be reads of objects corrupted before the upgrade」；恢复方案原话「This deletes valid offsets and group metadata in expired segments across every partition of the topic」。用户删掉旧记录后确认「The issue seems fixed now!」S30。__consumer_offsets 和所有 compacted topic（#3336 和 #3686 都出在这里）；用 Spot 实例或频繁滚动节点的 K8s 部署（#3686 的触发场景就是 Karpenter 替换节点）；从 1.7.1 之前的版本升级上来、存量对象可能已经损坏的集群。min.insync.replicas=2；Standard 的日志层是 Apache 原生实现。（解读）单个副本损坏时，其他副本上还有同一份数据，可以重新复制；单副本损坏后的具体恢复流程与耗时未做实测。Express 固定「replication is always set to 3 and the minimum in-sync replica is always set to 2」M20。cleanup.policy=compact 的 topic，用 kafka-verifiable-producer / -consumer 有序写入并校验读取，跑 48 h，期间每 30 分钟对一台 broker 发一次 SIGTERM；②用 iptables 对 S3 前缀列表随机丢包 / 限速，模拟 SDK 超时重试，同时写入，结束后全量回读并逐条做 CRC 校验。指标：确认写入数与读回数之差、损坏消息数、__consumer_offsets 中已提交 offset 是否回退。判据：全部为 0 才算通过。MSK Standard 用同一负载做对照。1.8 分支（下一个大版本，未发布）的 gradle.properties 是 version=3.9.2，main 是 version=3.9.0-SNAPSHOT S5。transaction.version=2、eligible.leader.replicas.version=1、kraft.version=1 实测。
UnsupportedVersionException）；Express「don't yet fully support KStreams API」M3。准确的说法是「MSK 在 4.x 主线上，能用到已经 GA 的 4.x 能力；AutoMQ 停在 3.9」，而不是「MSK 有 4.x 的全部功能」。kafka-features.sh describe，预期 metadata.version 最高 3.9-IV0，没有 transaction.version / group.version；②用 group.protocol=consumer 启动 consumer，预期报 UnsupportedVersionException 或回退到经典协议。对 MSK 4.1 集群做同样两步，预期成功。NOT_LEADER_OR_FOLLOWER，对照的是 Kafka 3.6.0 S25。）kill -9 单 broker）：AutoMQ 5.5.7 共 16 次全部自愈，最长零确认 15–27 s（最大单条确认 18.4–34.2 s）（测试记录 §10.4）；5.5.6 上 15 次中 3 次出现部分分区 32–44 min 不可写、需人工重启（测试记录 §9.3–§9.6）。实例终止未单独测。enable.idempotence=true、acks=all，KIP-679 原文「release version 3.0」S50）；用 Spot 或频繁滚动的部署（每次都要走一遍这条链）；kafka-go 等非 Java 客户端（PR #3459 原文：迁移窗口「can cause user-visible write failures」S38）。request.timeout.ms 的默认值 30 s 实测，因此对低延迟链路建议把它调到 10 s 量级（前提是开了幂等）。Express 的「no maintenance windows」也不等于没有影响 M6。enable.idempotence=true，其中 50 个带 transactional.id；每个 producer 100 msg/s × 1 KB。依次做三件事：计划内 kill -15、计划外 kill -9、强制停止 EC2。指标：每个分区「最后一次成功写 → 下一次成功写」的间隔（p50 / p99 / max）、每秒 produce p99、错误码计数（NOT_LEADER_OR_FOLLOWER、OUT_OF_ORDER_SEQUENCE_NUMBER、UNKNOWN_PRODUCER_ID）、按序号校验的重复与丢失。判据：计划外故障时分区不可写 p99 大于 5 s，或出现序号类错误，这一条成立。MSK 用同一脚本跑 RebootBroker 对照。AWS_MSK_IAM) and OAUTHBEARER are not mentioned」S9；迁移文档原文「Kafka Linking does not support MSK IAM Role authentication mode and only supports the native ACL authentication mode」S11。公开检索中没有找到 AutoMQ 支持 IAM 的说法，GitHub 上也没有 Kafka 客户端 IAM 认证的需求或计划。注意：这是「文档未列」，不等于已经证明不存在。AWS_MSK_IAM 的 MSK 客户。迁过去要改所有客户端的认证方式，而且迁移前要先在源 MSK 集群上开 SCRAM。另外，想用 IAM policy 直接授权到 topic / 消费组粒度的客户也受影响。sasl.mechanism=AWS_MSK_IAM 连 AutoMQ 开源 1.7.x。预期：UnsupportedSaslMechanismException。DataVolumeKMSKeyId, you can specify a customer managed key or the AWS managed key for MSK in your account (alias/aws/kafka). If you don't specify EncryptionAtRest, Amazon MSK still encrypts your data at rest under the AWS managed key.」M23。Deny s3:PutObject 的 bucket policy，持续 60 s 后撤销，期间 1,000 msg/s 持续写入。记录：produce 开始失败的时间点、恢复后积压消化的时间、broker 是否退出、分区是否需要人工干预。delivery.timeout.ms=120000 下停写 249 s，在 delivery.timeout.ms=30000 下 3 次中 2 次生产者永久卡死；非首选 AZ 网络分区停写 22.7–30 s。另有双 FSx 部署失去一套约 5 min 时停写 333–573 s，恢复后不自愈、须人工重启（2 / 2，测试记录 §10.23）。双 FSx 上线后不能安全回退：把 FSx 从 2 套缩回 1 套后，一台 broker 启动即崩溃循环、控制台任务无限挂起且不报错，唯一出路是删实例重建（AutoMQ 5.5.7，测试记录 §11.4–§11.5）。leader.imbalance.per.broker.percentage 调整都不能消除，§12.5），MSK Express 最坏一秒 89.9–117.7 s（期间仍有确认、零确认 0–29 s），AutoMQ 商业版 69.5–72.4 s；若丢的是 FSx 首选 AZ，AutoMQ 三个 AZ 的生产者全停 369–376 s、每路 ≈ 30 万笔失败（测试记录 §12.3））。offsets.retention.minutes「7 days – Customization not supported」；log.retention.ms 1 小时–60 天（超出要提工单）；fetch.max.bytes 55 MB。express.m7g.large 推荐 1000、最大 1500 M12；详见 §4.10。kafka-dump-log.sh --files，预期无法解析；②用 MSK Replicator（外部源、SCRAM、Identical 命名、Earliest）复制到 MSK Express，记录全量复制耗时、复制吞吐、消费组 offset 是否对齐。client.id 设成 automq_type=producer&automq_az=<client_az>，或在服务端配置 automq.zone.cidr.blocks，原因是「Due to limitations of the Kafka protocol, the server cannot be aware of the Rack to which the Client belongs」；consumer 用 KIP-881、设 client.rack、客户端 ≥ 3.5.0。
client.id 用于配额 / 监控的客户；IPv6 / 双栈 VPC。replica.selector.class M4，代价是 E2E +2.2 ms 实测。producer 侧，有 key 的写入 MSK 没有对等手段；无 key 写入可以用 KIP-1123，实测 p50 −0.86 ms（需要 4.4 客户端，默认关闭）。| # | 不足 | 依据（原文 / 来源） | 边界 | 影响谁 | MSK 的做法 | 如何验证 |
|---|---|---|---|---|---|---|
| 15 | KRaft controller 同时存 S3 对象元数据，有规模风险 | 「Metadata information of objects on S3 is stored in KRaft」S14；#3477（约 5,000 topic）：controller 事件队列饱和，broker「restart dozens of times in a single incident」，active controller 自行退出 S34 | 机制属实（单一来源）；#3477 已关闭（维护者说 #3369 已修），报告者没有确认；当前版本在 5,000 topic 下是否仍有问题：未公开，请向 AutoMQ 索取规模测试结果 | 几千个 topic、几万个分区的平台团队 | MSK 的 KRaft 只存集群元数据；每 broker 分区数超过推荐值时，MSK 直接拒绝配置变更（HighPartitionCountException），是「拒绝请求」，不是「把 controller 压垮」 |
1k / 3k / 5k topic 阶梯，每一档都滚动重启；看 controller 事件队列时延、broker 重启次数、是否出现 fatal fault |
| 16 | ZeroZone 路径的正确性缺陷 | #3647：retention 删段后，另一 AZ 的 snapshot 副本返回「UNKNOWN_SERVER_ERROR, not OFFSET_OUT_OF_RANGE, so it cannot reset and retries forever」，陈旧「12 days」；修复进 1.7.5（目前是 RC）；#3638 IPv6 open S35 |
1.7.4 上存在（GitHub issue）；多数在 1.7.5 RC 修复中 | 正是为省跨 AZ 费而选 AutoMQ 的客户；用 auto.offset.reset=earliest 的消费组；事务 / EOS 用户 |
MSK 的跨 AZ 省钱手段（KIP-392 / KIP-1123）是 Apache 原生协议，follower 是 ISR 里的真实副本 | 空闲分区 retention 删段后，在另一 AZ 用 earliest 起新消费组，看是否报 UNKNOWN_SERVER_ERROR |
| 17 | S3 SDK 传输层问题在 1.7 上只能手工规避 | #3675：默认 Netty S3 客户端「can repeatedly reconnect to one refused IP」，1.7 要在 bucket URI 里手工加 sdkImpl=crt；#3664 修复进 1.8.0（未发布）；PR #3682 在 1.8 换成 CRT 传输层并大幅升级 AWS SDK S37 |
对 1.7.x 属实（GitHub issue / PR） | 留在 1.7 稳定线的客户：要么带着已知问题，要么上 1.8，承受一次核心 I/O 路径的大变更 | MSK 由 AWS 托管升级 | toxiproxy 对 S3 响应注入「发完响应头就 FIN」，持续 10 分钟，看读许可指标能否恢复 |
| 18 | WAL 类型是集群级配置，换延迟档要再迁一次 | Fresha 原文「we can always move to EBS WAL … We are aware that this would require yet another migration」S41 | 单一用户报告 + 配置文档。MSK 的 Standard / Express 也是集群级选择，差别在于两者都是毫秒级 | 同一平台上既有日志类（可以慢、要便宜）又有交易类（要快）负载的客户 | MSK 同一集群里所有 topic 都是毫秒级写入；tiered 可以按 topic 开，不影响写延迟（tiered topic p99 9.37 vs 普通 9.70 ms 实测） | kafka-configs --describe --entity-type topics，确认没有 topic 级的 WAL 配置 |
| 19 | 文档里的物理参数有错 | 原文「Compared to the traditional 3-replica architecture based on EBS gp3 (approximately $0.60/GiB/month total), this can reduce storage costs by roughly 26×」S14；gp3 实际约 $0.08/GB-月，三副本 $0.24 对 S3 $0.023 ≈ 10× | 官方原文 | 拿 AutoMQ 文档做 TCO 的客户 | — | 请厂商书面确认 gp3 单价后重算 |
| 20 | 报告 CRITICAL CVE 的 issue 仍 open（2026-09-21 起） | #3617（2026-09-21 开，open）：「Release images ship bcprov-jdk18on 1.84 with open CRITICAL CVE-2026-8763」，「This blocks image admission in environments that enforce CVE policies」S36 | 官方仓库 issue，影响低 | 有镜像 CVE 准入门禁的企业 | 托管服务，镜像和依赖由 AWS 负责 | trivy image automqinc/automq:1.7.4-strimzi |
| 21 | 「sub-10ms P99」有前提 | AWS 实测（AutoMQ 5.5.7，测试记录 §10.12、§10.3、§10.19）：单分区 200 B、1k–20k msg/s p99 7.64–7.93 ms（1k 时 7.75 ms），50k msg/s 11.35 ms（以上为推荐客户端、默认 16 KiB 批；50k 是默认批的临界点、两轮不一致：§10.12 p99 11.35 ms 达标，r4 重建实例 42.75 ms 未达标）；客户端 batch 256 KiB + zstd 后单分区 1k–200k p99 7.74–9.10 ms、200k 8.66 ms，1 h 浸泡 p99.99 33.75 / max 88.82 ms（测试记录 §11.9）；24 分区 1k→50k p99 7.6–15.9 ms；默认客户端（zone router 开，24 分区 100 B）13.75 ms；4 h 浸泡 p99.99 32.65 ms、max 235.6 ms。（厂商公布 12.87 ms S21、17.50 ms S22。） | sub-10ms p99 在推荐客户端参数、中低速率下成立；默认客户端、多分区高速率下不成立；长尾在百毫秒级 | 拿营销口径做选型的客户 | — | 在客户自己的负载、分区数、客户端参数下复测 p50 / p99 / p99.99 |
| # | 不足 | 依据（原文 / 来源） | 边界 | 影响谁 | MSK 的做法 | 如何验证 / 要问什么 |
|---|---|---|---|---|---|---|
| 22 | 开源版自平衡只看网络吞吐；开源迁移只有 MM2，而且「requires downtime」 | 对比表原文「Basic scheduling strategy, balancing network throughput only」「Cluster switching requires downtime」S2 | 官方原文 | 自建开源版的客户 | Express Intelligent Rebalancing 新集群默认开启、不额外收费 M5（2025-11-20 之前建的 Express 集群默认 Paused） | — |
| 23 | SLA 文本停在 2023-12-16，只看 produce | 原文「Last updated: December 16, 2023」；不可用的定义是「fails to produce messages … lasts for more than one minute」S17 | 文本较早、只看 produce。「只赔服务抵扣」不是差异（MSK 也只给服务抵扣 M13） | 需要把消费可用性、延迟劣化写进 SLA 的客户 | — | 向厂商要最新 SLA 文本，以及 BYOC 下可用性怎么度量 |
| 24 | 合规覆盖面窄 | 只列 SOC 2 Type II、ISO 27001、GDPR；FedRAMP 原文是「align with」S20 | BYOC 下数据面在客户账号里，底层 EC2 / S3 本身在 AWS 合规范围内；差距在于 AutoMQ 作为运维方没有 PCI AOC，不能签 BAA ⇒ 需要客户合规团队确认，不等于「不能用」 | PCI、HIPAA、美国联邦负载 | MSK「These include PCI and HIPAA BAA」M8；FedRAMP Moderate（东 / 西）与 High（GovCloud）M8 | 向 Trust Center 申请 SOC 2 报告，看报告期和系统描述是否覆盖 BYOC 运维 |
| 25 | 24/7 支持要另外买 | Production 档「最低 $1,000/月」才有 24/7 和 P1 1 小时响应；「Product subscription billed separately」；范围之外包括「performance testing」「disaster-recovery exercises」「upgrade execution」，以及「cloud infrastructure, networks, Kubernetes, object storage」引起的问题 S18 | 支持另外收费本身不是差异（AWS Support 同样另外收费）。真正的差异是 BYOC 出事故时要分别给两家开工单，以及「对象存储引起的问题」不在支持范围内 | 7×24 交易 / 支付链路 | MSK 的补丁、升级、broker 替换都由 AWS 执行 M6 | — |
| 26 | GitHub「Latest」显示的是 RC | 1.7.5-rc2（2026-10-28）prerelease: false S38 |
影响小 | 自动拉「最新 release」的流水线会拉到 RC | — | — |
| 27 | Region 覆盖 | BYOC 列了 30 个 AWS 商业 Region，没有 GovCloud 和中国区；Azure 只有 8 个 S8 | 「文档没列」不等于不能部署，要问厂商 | GovCloud / 中国区客户 | MSK 在 GovCloud 有 FedRAMP High 范围 M8 | 对照自己的 Region 清单 |
| 28 | Table Topic 的限制 | Schema Registry「supports only」Confluent SR 和 Aiven Karapace；「AutoMQ automatically deletes snapshots that are older than one hour」；默认错误策略 invalid_data 跳过坏记录，文档没有提 DLQ；「must be configured at the time of deploying the AutoMQ cluster」S43 |
作为向 AutoMQ 确认的问题（见 §4.9） | 已经用 Glue SR 的 AWS 客户；需要 time travel 的客户 | 见 §4.9 | 见 §4.9 |
| 29 | 滚动重启后 broker IP 会变 | Fresha 原文「after a rolling restart, the IP addresses of the cluster might change, but the AdminClient might still have the old IPs cached」，要设 metadata.recovery.strategy（原文拼作「reboostrap」）S40 |
IaaS / ASG 形态，单一用户报告；4.x 客户端默认就是 rebootstrap | 还在用 3.x 客户端的 Connect、Debezium；按固定 IP 配白名单的防火墙 | — | Kafka 3.7 AdminClient + ASG instance refresh |
| 30 | 「免维护窗口」是案例稿的说法，AutoMQ 自己的博客否认 | AutoMQ 博客 FAQ 原文「Does AutoMQ eliminate Kafka maintenance windows? No. Production changes still require planning, monitoring, and coordination」S47（2026-06-01） | 官方博客原文。AWS 实测商业版：在线升级 5.5.6 → 5.5.7 用时 580 s、最大停顿 2.9 s、0 丢（测试记录 §10.2）；FSx 换档 384 → 768 MBps 用时 52.7–53.9 min、期间尖刺 ≤ 3.1 s（测试记录 §7.12、§10.9） | 因为 MSK 打补丁时的尖刺而考虑迁移的客户 | Standard / Express 重启实测见 #4 | 逐台重启 AutoMQ broker，按秒记 p99 和失败数，与 实测同口径对比 |
| 31 | 独立证据稀薄 | AWS Marketplace 两个商品分别是「0 ratings」和「1 ratings」S46；ToS 1.4(g) 禁止发布商业版基准 S15；公开延迟数据全部是厂商自测或联合发布 | 影响低 | 做采购评估的客户：拿不到同行的独立负面样本 | — | 要求两个同行业、非日志类负载、可以直接通话的参考客户 |
| 32 | 厂商 FSx p99 12.87 ms 来自一次短测试；长跑实测 p99 稳定，长尾在百毫秒级 | 博客里的压测命令带 --record-size 52224（约 51 KiB 大消息）、--test-duration 5 S21。AWS 实测（AutoMQ 5.5.7，测试记录 §10.19、§10.9）：单分区 20k msg/s 浸泡 4 h（2.88 亿条）p50 / p99 / p99.99 / max 6.16 / 7.87 / 32.65 / 235.6 ms，有 3 s 超过 100 ms；24 分区 2 h 浸泡 p99.99 55.85 ms、max 238.7 ms |
厂商短测与实测负载不同（51 KiB vs 200 B），两组数字不宜直接比 | 拿这个数字做低延迟选型的客户 | — | EFS WAL 下同样跑长测，记 p99 / p99.99 / max，以及 FSx / EFS 月费 |
以下几点常被拿来比较，但并不构成 AutoMQ 的劣势：
AutoMQ 对 MSK 的常见说法，逐条给出依据。
答：那个数字的算术是对的，但有几个前提：MSK 没开 follower fetching；Standard 用的是 26 台上一代 m5.large、没开 tiered；AutoMQ 一侧是 S3 WAL，计算器自己标的是「Latency ~500ms」。开 follower fetching 后，对 Express 的节省约 6.5%（vs-msk 那个负载）；计算器默认负载下，按 Express 每 broker 分区上限配齐 broker 后，AutoMQ 对 Express 仍便宜约 44%、对 Standard + tiered 约 10%，分区 ≤ 1,000 时 MSK Standard + tiered 反而便宜约 16%（§4.3.3）——而这些 AutoMQ 价格都对应 S3 WAL 档。另外，它的 FAQ 把 MSK 不收取的 broker 复制费算了进去 M1（§4.3.2）。建议用贵司真实的压缩后字节、保留期和读扇出，两边按同一口径重算。
答：能。商业版 + FSx WAL 单分区 200 B 写入确认 p99 7.75 ms、24 分区 7.6–15.9 ms，AWS 实测（AutoMQ 5.5.7，测试记录 §10.12、§10.3），同规格、各自调优的同轮对照（r4，m7g.xlarge 级）：AutoMQ 7.83 ms、MSK Express 7.96 ms、MSK Standard 4.58 ms（测试记录 §11.9），与 MSK 同一量级，我们不否认；但故障时的停写比 MSK 长（kill -9 15–27 s，FSx 首选 AZ 网络分区 120–146 s，S3 不可用 300 s 时 106–136 s，测试记录 §10.4、§10.5、§10.6）。请确认三点：① 开源版只有 S3 WAL，AutoMQ 自己写的是「P99 600+ milliseconds」S2；② FSx 是额外付费的存储，Multi-AZ 只覆盖 2 个 AZ S45；③ 贵司看到的「低延迟」和「零跨 AZ」是不是同一种 WAL 配置——AutoMQ 文档要求零跨 AZ 必须用 S3WAL S3，而它的博客说 FSx 也能做到，两者说法不一致，请让厂商书面确认。
答：扩缩不搬数据是真的，这是它的优势。实测商业版在线扩缩 3 ↔ 6 broker 期间写入最大延迟 0.1–0.3 s，受控关闭最大确认 2.4–2.52 s，AWS 实测（AutoMQ 5.5.7，测试记录 §10.9）；#3669 仍是 open S33。停写主要来自故障：kill -9 单 broker 最长零确认 15–27 s，FSx 首选 AZ 网络分区时全集群 120–146 s，单分区在短 delivery 超时下可能永久卡死（测试记录 §10.4、§10.5、§10.8）。MSK Express 有「scale up to 20x faster」和默认开启的自动再平衡 M3M5。建议 PoC 时测 kill -9 后每个分区的不可写时长。
答：这一说法已经过时。MSK 从 2026-08-10 起支持原地 ZK→KRaft 迁移，「without provisioning new infrastructure」，前提是先升到 3.9.x M9（2AZ 的 Standard 集群除外）。AWS 在东京区的 MSK 实测（3 × m7g.large 小集群）：有客户端记录的约 3 小时里 0 条发送失败、最坏一秒 49.7 ms（迁移开始后前 74 分钟没有客户端记录）。
答：会有。官方口径是 p99「typically high milliseconds, up to ~2 seconds」M6；AWS 在东京区的 MSK 实测中，单 broker 重启最坏一秒 p99 是 1.14 s 实测（Standard）/ 1.34 s 实测（Express），0 条失败（3 × *.m7g.large；xlarge 另测（11-08，单分区三路审计流最坏一秒）：Standard 1.10–2.24 s、Express 2.29–2.61 s，与 large 一致（测试记录 §12.3））。客户端 request.timeout.ms 用默认 30 s 时，升级中出现过一次 30.65 s 实测的停顿，建议调到 10 s 量级（前提是开了幂等）。AutoMQ 自己的博客也写「Does AutoMQ eliminate Kafka maintenance windows? No.」S47，它的受控重启同样有秒级写延迟问题 S33：实测受控关闭最大确认 2.4–2.52 s，在线升级 5.5.6 → 5.5.7 最大延迟 2.9 s、0 丢，AWS 实测（AutoMQ 5.5.7，测试记录 §10.9、§10.2）。
答：纸面数字属实（MSK Multi-AZ 是 99.9%）。请注意：AutoMQ 的 SLA 文本最后更新于 2023-12-16，「不可用」只按 produce 失败超过 1 分钟定义；BYOC 下云资源可用性由客户负责；赔付基数是付给 AutoMQ 的服务费 S17。两边都只给服务抵扣。
答：公开案例确实不少，但几乎都是日志、可观测性、数据总线、CDC 这类延迟不敏感的负载；公开资料中没有找到低延迟负载的生产 p99。另外，AutoMQ ToS 禁止发布商业版的基准和性能信息 S15，所以外界很难拿到独立数据。建议请 AutoMQ 提供同行业、非日志类负载、可以直接通话的参考客户。
答：属实，Serverless 的入向上限是 200 MBps、出向 400 MBps M12。高吞吐负载请用 Express 或 Standard。
架构逐环节对比、6 种形态的完整对比表，以及延迟、弹性、成本、可靠性、兼容性等 13 个专题。
| 环节 | MSK（Apache Kafka，shared-nothing） | AutoMQ（S3Stream，共享存储） |
|---|---|---|
| 写入耐久性来自哪里 | leader 写本地盘，ISR 中的 follower 跨 AZ 拉取复制；acks=all 表示至少写到 minISR 个副本（Express 固定 RF3 / minISR 2 M20） |
「Once the data is successfully written to WAL, confirmation is returned to the client」S1；Kafka 层 RF=1（#3686 的环境中是 replicas=[1000], isr=[1000] S30）；耐久性取决于 WAL 介质：S3 WAL 跨 AZ，EBS WAL 只在单 AZ，FSx 横跨 2 个 AZ S1S45 |
| 写 ack 延迟由什么决定 | 网络 RTT + 一轮复制（AWS 在东京区的 MSK 实测 p99 为 4.58–17.6 ms（调优后 4.58 ms，kafka.m7g.xlarge；默认 in-flight 5 时 17.6 ms，m7g.large），取决于客户端参数，见 §4.1）实测 | S3 WAL：攒批（默认 250 ms / 8 MiB S12）+ S3 PUT；EBS / EFS / FSx WAL 为毫秒级，但只在商业版 |
| 存储 | Standard：每个 broker 预置 EBS，三个副本都计费；可开 tiered storage（远端按单份计费）M7。Express：按实际用量计费的托管存储，「elastic, virtually unlimited, pay-as-you-go」M3 | S3 存单份，后台做 compaction；对象元数据存在 KRaft 里 S14 |
| 跨 AZ 流量 | broker 间复制免费 M1；客户端与 broker 之间的跨 AZ 流量按标准数据传输费收取（每个方向 $0.01/GB）；consumer 侧可用 follower fetching 消除 | producer 侧经 S3 中转给 leader（ZeroZone），文档要求 S3WAL S3；consumer 侧读本 AZ 的只读副本，依赖 KIP-881 + client.rack S3 |
| 换 leader / 迁移 | 切到 ISR 中已同步的 follower，数据不动；Standard 扩容要搬数据，Express 宣称「scale up to 20x faster」M3 | 先把未上传的 WAL 数据刷到 S3，再在另一个 broker 上打开分区，数据不动；在线扩缩 3 ↔ 6 broker 期间写入最大延迟 0.1–0.3 s，kill -9 单 broker 后最长零确认 15–27 s，AWS 实测（AutoMQ 5.5.7，测试记录 §10.9、§10.4） |
| 冷读 / 追读 | 读本地 EBS + page cache；AWS 在东京区的 MSK 实测中，Standard 在每 broker 写入超过 gp3 卷 250 MiB/s 吞吐基线（≈ 270 MB/s 灌入，3 × m7g.large）后出现过 p99 42 s 的停顿；轻写入时冷读只让 p99 增加 0.44 ms | 读 S3，与写路径隔离（30 GB 历史回读期间写路径最大延迟 257 ms，AWS 实测（AutoMQ 5.5.7，测试记录 §10.14）） |
各自的代价（基于上表事实的判断）：
两种架构搬运的字节量相当，AutoMQ 只是把 broker 间复制换成了 broker 与 S3 之间的流量。AutoMQ 文档原文：「each data write from a client translates into three network writes by the server」S13。在 AWS 上，同 Region 访问 S3 不收传输费，所以这笔账在成本上成立。但「没有复制」不等于网络字节消失了；同时 Kafka RF3 的出向流量也在同一量级，这一点本身不构成 AutoMQ 的劣势。
格内编号对应来源列表。「—」= 不适用；「未公开」= 没有找到公开信息；⏳ = 来源早于 2025-10-29，超过 12 个月，可能过时。MSK 三列的时延与重启数据为 AWS 在东京区的 MSK 实测：时延按 r4（kafka / express.m7g.xlarge，客户端调优）与早一轮（*.m7g.large）分别标注；重启数据为 *.m7g.large。
列定义：AutoMQ BYOC = 控制面 + 数据面都部署在客户云账号里的商业版 S19；AutoMQ Cloud = docs.automq.com/automq-cloud/* 文档描述的范围（restrictions 页的限制写在这里 S8；SLA 文本里提到的厂商账号托管 SaaS 形态是否在售：未公开）。另列开源版，因为 AutoMQ 的多数不足（§0）按版本区分。
| 维度 | MSK Standard | MSK Express | MSK Serverless | AutoMQ 开源版 | AutoMQ BYOC | AutoMQ Cloud（文档范围） |
|---|---|---|---|---|---|---|
| 交付模型 | AWS 托管，broker 在服务账号里，通过 ENI 接入客户 VPC | 同左 | 全托管，免容量规划 M19 | 自建自运维 S2 | 部署在客户账号里，由 AutoMQ 远程运维 S19 | 同 BYOC 文档 |
| 写 ack p99（测试条件各不相同，见 §4.1） | 4.58 ms（r4，xlarge，调优）/ 17.6 ms（m7g.large，默认 in-flight 5）[LAB] | 7.96 ms（r4，xlarge，调优）/ 8.0–10.4 ms（large，in-flight 1）[LAB] | 7.18 ms（in-flight 1，IAM）[LAB] | 「P99 600+ milliseconds」S2；基准 P99 823 ms S23 | FSx WAL 7.83 ms（r4，单分区 200 B）/ 7.6–15.9 ms（24 分区），AWS 实测（AutoMQ 5.5.7，测试记录 §11.9、§10.3）；EBS WAL 稳态 p99：未公开；EFS WAL：未公开 | 同 BYOC |
| Kafka 层副本 | RF 可配（通常 3） | 固定 RF3 / minISR 2 M20 | 默认 RF3 / minISR 2（AWS 在东京区的 MSK 实测） | RF=1 S30 | RF=1 | RF=1 |
| broker 间复制费 | 0 M1 | 0 M1 | 0 | —（无复制） | — | — |
| 客户端跨 AZ 费 | 收；consumer 侧用 follower fetching 可降到约 0 | 收；可配 replica.selector.class M4 |
同 Region 客户端流量不另收传输费 M2 | 前提满足时 producer / consumer 都约 0（S3WAL、3 AZ、均衡、改 client.id）S3 |
同左；FSx WAL 宣称「near-zero」，与其文档说法不一致 S21S22 | 同 BYOC |
| 存储计费 | 每副本预置 EBS $0.10/GB-月；tiered $0.06（单份）M1 | $0.10/GB-月，按用量（单份）M1 | $0.10/GB-月 M1 | S3 $0.023 + 请求费（客户自付） | S3 + 请求费 + AutoMQ 保留费 $0.005–0.01/GiB-月 S27 | 同 BYOC |
| 计算 / 吞吐计费 | broker 小时（m7g.large $0.204/h，us-east-1）M1 | broker 小时（express.m7g.large $0.408/h）+ 写入 $0.01/GB M1 | 集群小时 + 分区小时 + 写入 $0.10 / 读出 $0.05 每 GB M1 | EC2 自付 | EC2 自付 + 写入 $0.008–0.02/GiB + 读出 $0.00275–0.0067/GiB + $0.411/h S27；或 AKU $146/月（30 MiB/s 写或 60 MiB/s 读）S46 | 同 BYOC |
| 承诺折扣 | 无 RI M2 | 无 RI | 无 RI | EC2 可用 RI / SP / Spot | 同左 | — |
| 扩缩容 | 扩容要搬数据；可以删 broker，但要先把分区迁走（「first move all partitions … from the brokers you plan to remove」M24）；EBS 不能缩 | 「scale up to 20x faster」（相对 Standard，未给绝对秒数）M3 | 自动 M19 | 迁移最大发送延迟 2.2 s；0→1 GiB/s 扩容约 4 分钟（厂商自测）S25 | 在线扩缩 3 ↔ 6 broker 期间写入最大延迟 0.1–0.3 s；FSx 换档 384 → 768 MBps 用时 52.7–53.9 min、期间尖刺 ≤ 3.1 s，AWS 实测（AutoMQ 5.5.7，测试记录 §10.9） | 同 BYOC |
| 自动再平衡 | 无（需自管 Cruise Control） | Intelligent Rebalancing，新集群默认开启、免费 M5 | 托管 | 只看网络吞吐 S2 | 网络 + QPS + 冷读积压 + 慢节点隔离 S2 | 同 BYOC |
| 维护 | 滚动重启；p99「up to ~2 seconds」M6；实测 1.14 s 实测 | 「no maintenance windows」，仍有单 broker 重启；实测 1.34 s（3 × express.m7g.large；xlarge 另测（11-08，单分区三路审计流最坏一秒）：Standard 1.10–2.24 s、Express 2.29–2.61 s，与 large 一致（测试记录 §12.3）） 实测 | 托管 | 自行维护 | 托管；AutoMQ 自己的博客表示不能消除维护窗口 S47；#3669 仍为 open S33；在线升级 5.5.6 → 5.5.7 用时 580 s、最大延迟 2.9 s、0 丢，受控关闭最大确认 2.4–2.52 s，AWS 实测（AutoMQ 5.5.7，测试记录 §10.2、§10.9） | 同 BYOC |
| Kafka 版本 | 4.0 / 4.1（及 3.x）M11 | 3.6、3.8、3.9、4.2 M3 | 未公开 | 3.9.x 内核 S5 | 兼容「0.9.0.x ~ 3.9.x」（release notes） | 同 BYOC |
| 认证 | IAM、SCRAM、mTLS、未认证 M16 | 同左 | 只支持 IAM M19 | Kafka 原生（SCRAM / PLAIN / mTLS） | SCRAM / PLAIN / mTLS，文档未列 IAM / OAUTHBEARER S9 | 同 BYOC |
| 静态加密 | KMS，可用客户托管密钥（CMK）M23 | 同左（以 Express 文档为准） | KMS（是否支持 CMK：以 Serverless 文档为准） | 自管 | 云厂商托管密钥，不支持 BYOK，只在 AWS，建好后不能改 S10 | 同 BYOC |
| 合规 | PCI、HIPAA BAA、SOC、FedRAMP M8 | 同左（以服务范围页为准） | 同左（以服务范围页为准） | — | SOC 2 Type II、ISO 27001、GDPR S20；BYOC 底层资源在客户账号里 | 同 BYOC |
| SLA | Multi-AZ 99.9%，服务抵扣 M13 ⏳ | SLA 页早于 Express 发布，未单列 | 未单列 | 无 | 99.95%，服务抵扣，只按 produce 定义可用性 S17 ⏳ | 同左 |
| 多云 | AWS | AWS | AWS | 任意 S3 兼容存储 | AWS / GCP / Azure / OCI | 同左 |
| 入湖 | 不支持 Data Delivery | Data Delivery to S3 / Streaming Tables（Iceberg），2026-07-30 GA M14 | 不支持 | Table Topic 是否在开源版：未公开 | Table Topic（Upsert / CDC、Avro / Protobuf、多种 Catalog）S43 | 同 BYOC |
| 迁移工具 | MSK Replicator（外部源含 AutoMQ）M2M15 | 同左 | — | MM2（「requires downtime」）S2 | Kafka Linking，只能迁入，不支持 MSK IAM 源 S11 | 同 BYOC |
| 单分区 / 配额限制 | broker 规格配额；每 broker 分区数有推荐值，超出时拒绝配置变更（HighPartitionCountException，AWS 在东京区的 MSK 实测）；单分区实测 batch 256 KiB + zstd 后 200k msg/s × 200 B（kafka.m7g.xlarge） |
单分区写「Max 15 MB/s」（实测 ≈ 22 MB/s，超过文档值，express.m7g.xlarge）；每 broker 分区数（含副本）推荐 / 最大，如 large 1000 / 1500 M12 | ingress 200 MBps、egress 400 MBps、2,400 个 leader 分区 M12 | 未公开；实测 1.7.4 调大批后 100k msg/s 跟上，p50 ≈ 355–365 ms | 未公开；实测 200k msg/s（batch 256 KiB + zstd）p99 8.66 ms | 单分区读写各 4 MBps，offsets 固定 7 天，保留期 ≤ 60 天 S8 |
| GovCloud / 中国区 | GovCloud 在 FedRAMP High 范围内 M8 | 同左 | 以 Region 表为准 | 自建 | 文档未列 S8 | 同左 |
AWS 在东京区的 MSK 实测（m7g.large × 3 AZ，集群内 TLS，200 B，1,000 msg/s，acks=all，客户端与 leader 同 AZ，2026-10-28）：
| 形态 / 客户端参数 | 写 ack p50 / p99 | E2E p50 / p99 |
|---|---|---|
| Standard，in-flight 1，linger 0 | 3.28 / 5.72 ms 实测 | 3.6 / 6.2 ms |
| Standard，默认 in-flight 5，linger 0 | 11.5 / 17.6 ms 实测 | — |
| Standard，linger 5 + in-flight 5（4.x 默认组合） | 5.1–5.3 / 8.0–8.3 ms | — |
| Express，in-flight 1，linger 0 | 3.6–3.9 / 8.0–10.4 ms | — |
| Express，linger 0 + in-flight 5 | 13.0–13.6 / 21–30 ms | — |
| Serverless（IAM，in-flight 1） | 5.35 / 7.18 ms | 6.08 / 8.20 ms |
| Standard RF3，leader 在远 AZ | 5.74 / 8.05 ms | 5.87 / 8.34 ms |
AutoMQ 数字（厂商公布值条件各不相同；FSx WAL 另有 AWS 实测行）：
| WAL | p99（写 / send） | E2E p99 | 条件 | 来源 |
|---|---|---|---|---|
| S3 WAL（开源） | 823 ms（P999 1,049） | 1,189 ms | 1 GiB/s，6 节点，256 分区，1 KiB，linger.ms=100 |
S23 |
| S3 WAL | 489 ms（send） | — | 条件未完整公开 | S24 |
| S3 WAL（对比表） | 「600+ milliseconds」 | — | 未给条件 | S2 |
| FSx WAL（AWS 实测，5.5.7，200 B） | 单分区 7.75 ms（p50 6.64）；24 分区 1k–50k msg/s 时 7.6–15.9 ms；4 h 浸泡 p99.99 32.65 ms、max 235.6 ms | — | 3 × m7g.xlarge，FSx 384 MBps 档，3 AZ，1,000 msg/s，acks=all + 幂等，in-flight 5 / linger 1 |
测试记录 §10.12、§10.3、§10.19 |
| FSx WAL（AWS 实测，5.5.7，r4 调优） | 单分区 1k 7.83 ms（p50 6.71）；1k–200k 7.74–9.10 ms；1 h 浸泡 p99.99 33.75、max 88.82 ms | — | 3 × m7g.xlarge，单 FSx，batch 256 KiB · zstd · in-flight 5 · linger 1 | 测试记录 §11.9 |
| FSx for ONTAP WAL | 12.87 ms（avg 5.98） | 18.04 ms | 厂商公布，约 51 KiB 大消息、5 s 短测；3 × m7g.4xlarge，300 MBps | S21 |
| FSx for ONTAP WAL | 17.50 ms（avg 6.34） | 28.00 ms | 厂商公布；6 × m7g.4xlarge | S22 |
| EBS / EFS WAL | 未公开 | 未公开 | — | — |
解读：
acks=all、3 AZ）实测 AutoMQ 商业版 FSx WAL：单分区 p99 7.75 ms，24 分区 p99 7.6–15.9 ms，AWS 实测（AutoMQ 5.5.7，测试记录 §10.12、§10.3）。同规格、各自调优的同轮对照（r4，m7g.xlarge 级）：1k p99 Standard 4.58 / AutoMQ 7.83 / Express 7.96 ms（测试记录 §11.9）。建议向 AutoMQ 提的问题：在贵司的负载（消息大小、速率、acks=all、3 AZ）、指定 WAL 类型下，produce 与 E2E 的 p50 / p99 / p99.9 分别是多少？EBS / EFS WAL 的稳态 p99 是多少？
如何在 PoC 中自己验证：EC2 上部署 AutoMQ 开源 1.7.x（3 AZ × 3 × m7g.xlarge，S3 WAL 默认参数），用与上表相同的负载（200 B、1,000 msg/s、acks=all、linger 0，in-flight 1 和 5 各一组），再加一组 10 MiB/s × 1 KB、linger 5；记录 produce p50 / p99 / p99.9 和 E2E p99，同 AZ 与远 AZ consumer 分开记录。MSK 侧用默认参数和调优参数各报一套。商业版试用的结果仅供内部评估。
建议向 AutoMQ 提的问题：持续自平衡下，每小时会触发多少次分区迁移？每次迁移期间 producer 看到的最大发送延迟和错误码是什么？
如何在 PoC 中自己验证：在 AutoMQ 开源 1.7.x 上持续写入，触发扩容与再平衡，按秒记录 produce p99、NOT_LEADER_OR_FOLLOWER 计数和每个分区「最后一次成功写 → 下一次成功写」的间隔；MSK Express 用同一脚本扩容对照。
说明：本节所有算例都是推导，没有经过 AWS Pricing Calculator 复核，不是报价；请按自身负载重算。
负载原文：「100 MiB/s write · 300 MiB/s read · 5,000 partitions · 72h retention」S26。图上不显示数值，下列数字按柱高换算（误差约 ±$1）：
| 项（$/月） | MSK Standard | MSK Express | AutoMQ |
|---|---|---|---|
| Compute | 并入 Managed | 并入 Managed | 357 |
| Storage | 并入 Managed | 并入 Managed | 1,173 |
| Cross-AZ | 13,688 | 13,688 | 0 |
| Managed Service | 19,174 | 9,267 | 10,329 |
| 合计 | 32,862 | 22,955 | 11,859 |
算术成立，但前提有偏：
建议向 AutoMQ 提的问题：在 MSK 开启 follower fetching、使用当代实例和 tiered storage、并且 AutoMQ 使用与 MSK 同一延迟档位的 WAL 时，节省比例是多少？
计算器默认值原文：「WAL: S3 WAL, Fanout: 1, Requests: 2,000/s, Partitions: 2,000, Retention: 168h」；反推平均写入约 10 MiB/s；us-east-1 S27。
| 方案 | 月成本 | 与 AutoMQ $1,664 比 | 说明 |
|---|---|---|---|
| AutoMQ（S3 WAL） | $1,664 | — | EC2 $84 + EBS $5 + S3 存储 $136 + S3 请求 $395 + Uptime $300 + 写入 $513 + 读出 $172 + 保留 $59；其中付给 AutoMQ $1,044 S27 |
| MSK Standard，计算器原口径 | $4,841 | AutoMQ 称省 66% | 4 × m5.large；存储 35,438 GiB = 逻辑量 × 6（RF3 × 50% 利用率）；读 leader |
| MSK Express，计算器原口径 | $2,425 | AutoMQ 称省 31% | 3 × m7g.large $894 + 存储 $591 + 写入 $257 + 跨 AZ 342 + 342 |
| MSK Express + follower fetching，6 × express.m7g.large（每台 1,000 个副本 = 推荐值） | ≈ $2,976 | AutoMQ 便宜约 44% | $2,083 − $894 + 6 × $0.408 × 730（$1,787）；3 × express.m7g.xlarge（推荐 1,000、最大 2,000，$0.816/h）同为 $1,787（推导） |
| MSK Express + follower fetching，分区 ≤ 1,000（3 × express.m7g.large 即可） | ≈ $2,083 | AutoMQ 便宜约 20% | 仅在分区 ≤ 1,000 时成立 |
| MSK Standard 6 × m7g.large + tiered（本地保留 12 h）+ follower fetching | ≈ $1,843 | AutoMQ 便宜约 10% | broker $894（2,000 分区 × RF3 = 6,000 副本，按每 broker 1,000 个推荐值配 6 台）+ 本地 EBS $253 + tiered $354（5,906 GiB × $0.06）+ producer 跨 AZ $342 |
| 同上，但分区 ≤ 1,000（3 × m7g.large 即可） | ≈ $1,396 | MSK 便宜约 16% | 同上 |
express.m7g.large 上每台 2,000 个，超过其最大值 1,500（推荐 1,000）M12，配置不可行；放在 3 台 Standard m7g.large 上每台 2,000 个，是推荐值的 2 倍，会被 MSK 的 HighPartitionCountException 拒绝，AWS 在东京区的 MSK 实测中 p99 也会恶化约 6 倍。如何在 PoC 中自己验证：AutoMQ 开源 1.7.x，每个 broker 的写速率按 1 / 5 / 16 / 32 / 64 / 170 MiB/s 扫一遍；用 S3 请求指标统计 PUT / GET 次数 × 单价，除以写入 GiB，得到每 GiB 的请求费，再与 MSK 侧 producer 跨 AZ 单价对比。
| 手段 | 效果 | 来源 | 代价 / 边界 |
|---|---|---|---|
| broker 间复制免费 | 自建 Kafka 中最大的一段跨 AZ 费，在 MSK 上为 0 | M1 | — |
| Follower fetching（KIP-392） | consumer 跨 AZ 降到约 0；在 vs-msk 那个负载下一项就省 $10,266/月 | M4 | E2E +2.2 ms 实测；client.rack 必须填 AZ ID |
| KIP-1123 rack-aware partitioner | 无 key 写入导向同 AZ 的 leader，AWS 在东京区的 MSK 实测 p50 −0.86 ms | — | 只对无 key、未指定分区的记录有效；需要 4.4 客户端；默认关闭 |
| 压缩（zstd level 1） | AWS 在东京区的 MSK 实测吞吐为不压缩的 4.8 倍，p99 同时下降；同时减少跨 AZ、存储和 Express 写入费 | — | 必须用真实 payload 测，随机字节没有收益 |
| Tiered storage（Standard） | 每逻辑 GB 存储成本约为 EBS 的 1/6–1/5 | M7 | 远端读吞吐约 1/7、首条 1.17 s 实测；最短远端保留 3 天，不支持 compacted topic M7 |
| Express | 存储按用量计费，无需预置；自动再平衡 | M3M5 | 小时单价是同规格 Standard 的 2 倍；存储 $0.10/GB-月，约为 S3 的 4 倍 |
| 商务协议 | EDP / PPA | — | MSK 没有 RI M2 |
建议向 AutoMQ 提的问题：硬崩溃（kill -9、实例终止）后分区的接管时间是多少？对象存储不可写时 broker 的行为和恢复步骤是什么？升级到修复版本前已损坏的对象如何发现和修复？
如何在 PoC 中自己验证：
enable.idempotence=true（其中 50 个带 transactional.id），每个 100 msg/s × 1 KB；依次做 kill -15、kill -9、强制停止 EC2，记录每个分区的不可写间隔（p50 / p99 / max）、每秒 produce p99、错误码计数和按序号校验的重复与丢失。MSK 用同一脚本跑 RebootBroker 对照。cleanup.policy=compact 的 topic，用 kafka-verifiable-producer / -consumer 有序写入并校验，跑 48 h，每 30 分钟对一台 broker 发 SIGTERM；结束后全量回读做 CRC 校验，检查 __consumer_offsets 中已提交 offset 是否回退。判据：差异全部为 0 才算通过。Deny s3:PutObject 的 bucket policy，持续 60 s 后撤销，期间 1,000 msg/s 持续写入；记录 produce 开始失败的时间点、恢复后积压消化时间、broker 是否退出、分区是否需要人工干预。AutoMQ 的内核停在 Kafka 3.9（§0 #3）：下一个大版本的 1.8 分支 gradle.properties 仍是 version=3.9.2 S5；Apache 下载页已把 3.9.x 列入 Archived Releases S6，而 AutoMQ 文档写的是「It supports the latest updates to Apache Kafka versions within T+1 month」S4。#2950「Kafka 4.x kernel support」仍 open，维护者原话「we will need to maintain parallel development for two versions」，未给日期 S7。
| 能力 | Apache Kafka | MSK | AutoMQ（3.9 内核） |
|---|---|---|---|
| KIP-848 新 consumer 协议 | 4.0 GA | 4.x 可用；AWS 在东京区的 MSK 实测 E2E 与 classic 相同 | 3.9 只有 Preview 级代码（推断，依据基线 S5） |
| KIP-890 TV2 / KIP-966 ELR | 4.0 / 4.1 | 升到 4.1 后自动 finalize 实测 | 不可用（推断）；ELR 对 RF=1 不适用 |
| KIP-932 share groups | 4.2 production-ready | ❌ AWS 在东京区的 MSK 实测不可用 | ❌ |
| KIP-1071 Streams 协议 | 4.2 GA | Express 4.2 有，但「don't yet fully support KStreams API」M3 | ❌ |
| KIP-405 tiered storage | 3.9 production-ready | Standard 支持 M7 | 带 remote.storage.enable 的配置报错 S40 |
| 「100% 兼容」 | — | — | 自称「passed Apache Kafka's 500+ system test cases (KRaft mode)」S4；基线停在 3.9 |
说明：MSK 也不具备 4.x 的全部功能（如 share groups）；准确的说法是「MSK 在 4.x 主线上，能用到已经 GA 的 4.x 能力；AutoMQ 停在 3.9」。
建议向 AutoMQ 提的问题：4.x 内核的书面时间表是什么？在 3.9 被 Apache 归档后，安全修复如何获得？
如何在 PoC 中自己验证：AutoMQ 1.7.x + Java 4.4.0 客户端：①kafka-features.sh describe，预期 metadata.version 最高 3.9-IV0，没有 transaction.version / group.version；②用 group.protocol=consumer 启动 consumer，预期报 UnsupportedVersionException 或回退到经典协议。对 MSK 4.1 集群做同样两步，预期成功。
AWS_MSK_IAM) and OAUTHBEARER are not mentioned」S9；迁移文档原文「Kafka Linking does not support MSK IAM Role authentication mode and only supports the native ACL authentication mode」S11。（措辞为「文档未列」，不等于已证明不存在。）现网用 AWS_MSK_IAM 的客户迁移时需要改造所有客户端的认证方式。如何在 PoC 中自己验证：Java 客户端配 sasl.mechanism=AWS_MSK_IAM 连接 AutoMQ 开源 1.7.x，预期报 UnsupportedSaslMechanismException。
| 职责 | MSK | AutoMQ BYOC |
|---|---|---|
| 补丁 / 漏洞修复 | AWS：「Periodically, Amazon MSK updates software on the brokers」M6 | 「System Vulnerability Patching: AutoMQ Responsible」S17 |
| 云资源容量 | AWS | 客户「ensure cloud resource availability」S17 |
| 客户侧变更 | （解读）客户 VPC / 客户端侧变更无需事先通知 AWS；broker 侧 OS / 网络由 AWS 管理 | 改 OS / 网络前需提前 48 小时书面通知 AutoMQ（ToS 1.5.4）S15；「Customer are liable for service interruptions … caused directly or indirectly by your cloud or provided infrastructure」（1.5.3）S15 |
| 诊断数据 | 留在 AWS 服务侧 | Ops Bucket 跨账号授权给 AutoMQ 主账号 |
| 网络连通 | MSK FAQ：「all network traffic stays within the AWS network and is not accessible to the internet by default」M2 | 营销页「Maintains zero network connections between your VPC and AutoMQ」S19；但其文档要求控制台「must have internet access to download installation packages and synchronize necessary metadata」，并为 Ops Bucket 授权跨账号访问。AutoMQ 安全页原文：「AutoMQ cannot access your Kafka data or metadata without your authorization」S20 |
| 支持 | AWS Support（另外付费）；Enterprise Support 业务关键宕机 <15 分钟 M22 | 订阅之外另买：Production 档最低 $1,000/月，P1 1 小时；Enterprise 档 30 分钟；支持范围不含对象存储、云、K8s 引起的问题 S18 |
| 工单入口 | 一个（Kafka、网络、IAM、EC2、S3 都在 AWS） | 两个（AutoMQ + 云厂商） |
建议向 AutoMQ 提的问题：BYOC「零网络连接」与控制台需出网、Ops Bucket 跨账号授权如何同时成立？由对象存储或云资源引起的事故，由谁负责定位和恢复？
0.47」S48；Strimzi 1.x 只支持 Kafka 4.1+，与 3.9 内核冲突（用户原话「we're blocked on 0.45.x」S7）。MSK 一侧有 Topic API（2026-02-11 起支持 Create / Update / Delete，要求 Kafka 3.6+）M10，Terraform aws_msk_topic 在 provider v6.38.0（2026-03-25）发布 M21。trivy image automqinc/automq:1.7.4-strimzi 自行核对。| 维度 | MSK Data Delivery / Streaming Tables（Express，2026-07-30 GA M14） | AutoMQ Table Topic S43 | 谁占优 |
|---|---|---|---|
| 在哪里运行 | 从 Express 内部存储直接读，「no broker egress throughput」M14 | 「embedded streaming table architecture」，在 broker 内完成 | MSK（不占 broker 资源；AutoMQ 侧的资源开销未公开） |
| 前置依赖 | S3 Tables + Glue SR，都是托管服务 | 客户自备外部 Catalog；Schema Registry「supports only」Confluent SR / Aiven Karapace | MSK 托管程度更高；AutoMQ 更开放 |
| 格式 | JSON、JSON Schema（GSR） | raw、string、Avro / Protobuf（Confluent wire format） | AutoMQ |
| 写入语义 | append | append；配 id 列后支持 Upsert / CDC | AutoMQ |
| 新鲜度 | 5–15 分钟 | commit.interval.ms 默认 60 s；AutoMQ 自己提示「Frequent commits may result in commit conflicts and MetadataFile bloat」 |
AutoMQ |
| Catalog / 分区 | S3 Tables 托管表；只有时间分区 | rest、glue、tablebucket、nessie、hive；bucket / truncate / 时间分区 | AutoMQ |
| 坏记录 | 必须配 DLQ，坏记录带错误上下文进 DLQ，管道继续 | 默认 invalid_data 跳过坏记录，文档未提 DLQ |
MSK（默认留痕） |
| 表维护 | inline compaction 内置 | 「Regular table maintenance is necessary through compaction」（接 S3 Tables 时可借用其维护） | MSK |
| 快照 | S3 Tables 管理 | 「AutoMQ automatically deletes snapshots that are older than one hour」 | MSK |
| 启用时机 | 对已有 Express 集群开启 | 「must be configured at the time of deploying the AutoMQ cluster」 | MSK |
| 价格 | S3 Tables $0.010/GB，S3 通用桶 $0.008/GB M1 | 未公开 | — |
解读：在入湖功能广度上，AutoMQ Table Topic 目前更全。MSK 的优势在于托管、不占 broker 资源、坏记录必进 DLQ、inline compaction、对已有集群直接开启。需要 CDC 入 Iceberg 的场景，目前可以用 Managed Service for Apache Flink 或 MSK Connect 的 Iceberg sink。
建议向 AutoMQ 提的问题：快照 1 小时自动清理对 time travel 有何影响？默认跳过坏记录时如何审计丢弃的数据？是否支持 Glue Schema Registry？表 compaction 由谁负责？已有集群能否开启 Table Topic？Table Topic 对 broker 资源的开销是多少？
| 项 | MSK | AutoMQ |
|---|---|---|
| 每 broker 分区数 | Express 有推荐值和最大值（含 leader 与 follower 副本）：large 1,000 / 1,500、xlarge 1,000 / 2,000、2xlarge 2,500 / 4,000、4xlarge 6,000 / 8,000、16xlarge 20,000 / 32,000 M12；Standard 超过推荐值时，配置变更会被 HighPartitionCountException 拒绝，AWS 在东京区的 MSK 实测中 p99 恶化约 6 倍 |
开源版 / BYOC 的每 broker、每集群分区上限：未公开。Kafka 层 RF=1，同样分区数下副本数是 RF3 的 1/3（解读） |
| 单分区吞吐 | Express 文档「Max 15 MB/s」M12，AWS 实测 express.m7g.xlarge 单分区不压缩确认 ≈ 22 MB/s（99,990 msg/s）；Standard 单分区上限主要由客户端 batch.size / 压缩决定：默认 16 KiB 批确认 32,120/s，batch 256 KiB + zstd 后 200k msg/s（p99 5.84 ms），AWS 实测（kafka.m7g.xlarge） | AutoMQ Cloud 文档：读、写各 4 MBps，「Custom modifications are not supported」S8；BYOC（FSx WAL）：默认 16 KiB 批 100k 过载（最多确认 62,780/s），batch 256 KiB + zstd 后 200k msg/s p99 8.66 ms；开源 1.7.4：batch 512 KiB · linger 5 · zstd · in-flight 5 时 100k msg/s 跟上，但 p50 恒 ≈ 355–365 ms，AWS 实测（m7g.xlarge，测试记录 §11.9） |
| 其他硬限制 | — | AutoMQ Cloud 文档：offsets.retention.minutes「7 days – Customization not supported」；log.retention.ms 1 小时–60 天 S8（仅适用于 AutoMQ Cloud 文档范围） |
| 元数据规模 | KRaft 只存集群元数据 | 「Metadata information of objects on S3 is stored in KRaft」S14；#3477 在约 5,000 topic 时 controller 事件队列饱和，broker「restart dozens of times in a single incident」S34；该 issue 已关闭，但报告者未确认修复后复测 |
| Serverless | 2,400 个 leader 分区、ingress 200 MBps / egress 400 MBps M12 | — |
解读：RF=1 让 AutoMQ 在「同样分区数需要几台 broker」上具有结构性优势，这也是 §4.3.3 中 Express 算例需要配 6 台的原因；MSK 侧要按真实分区数配 broker，不能只按吞吐配。AutoMQ 的规模风险点不在副本数，而在 KRaft 中的对象元数据规模（§0 #15）。
建议向 AutoMQ 提的问题：BYOC / 开源版每 broker、每集群的分区与 topic 上限是多少？AutoMQ Cloud 的单分区 4 MBps、offset 7 天、保留 60 天限制是否适用于 BYOC？
如何在 PoC 中自己验证：按 1k / 3k / 5k topic 阶梯建 topic，每一档都滚动重启，观察 controller 事件队列时延、broker 重启次数、是否出现 fatal fault。同时把自身最热分区的峰值流量、最长保留期、消费组最长不提交间隔与上述限制逐一对照。
enable.idempotence=true、acks=all S50，（解读）即大多数 Java 客户端默认就处在这个待验证的场景中。transaction.version=2 实测；Express「don't yet fully support KStreams API」M3，KIP-1071 只在 Express 4.2 上提供（§4.5）。⇒ 重度 Kafka Streams 用户在 MSK 上建议优先选择 Standard。建议向 AutoMQ 提的问题：开启幂等 / 事务的大规模部署中，broker 切换时的 producer 状态重建耗时和错误码分布是什么？
如何在 PoC 中自己验证：50 个带 transactional.id 的 producer + read_committed consumer，做故障注入后统计中止事务的可见数、OUT_OF_ORDER_SEQUENCE_NUMBER / UNKNOWN_PRODUCER_ID 计数；ZeroZone 开 / 关各跑一遍。MSK 用同一脚本对照。
EARLIEST + Identical 命名 + synchroniseConsumerGroupOffsets=true；如需回滚，建反向 Replicator 并设 consumerGroupOffsetSyncMode=ENHANCED；约 30 分钟进入 RUNNING。automq.* 等 AutoMQ 私有 topic 配置在 Identical 模式下如何处理尚未确认，PoC 时先列出所有 topic 配置做比对；③offset 同步是翻译 / 近似，不是字节一致。如何在 PoC 中自己验证：在 AutoMQ 开源版上灌 200 GiB（48 分区，保留 30 天）：①从 bucket 中任取一个对象跑 kafka-dump-log.sh --files，预期无法解析；②用 MSK Replicator（外部源、SCRAM、Identical 命名、Earliest）复制到 MSK Express，记录全量复制耗时、复制吞吐、消费组 offset 是否对齐。
| 项 | MSK | AutoMQ |
|---|---|---|
| 机制 | MSK Replicator 异步复制，含 topic 配置、ACL、消费组 offset M15 | Multi-Region Cluster（Enterprise 档）；实现细节未公开 |
| RPO | 异步；AWS 在东京区的 MSK 实测同 Region 复制延迟 p50 约 280 ms / p99 约 527 ms 实测，跨 Region 未测 | 宣称「RPO = 0」S51（无独立验证） |
| RTO | 取决于客户端切换（DNS / 配置）与应用重启，无公开数字 | 宣称「Seconds-Level Failover (RTO ≈ 10s)」S51 |
| 定价 | Replicator 按小时 + 每 GB 处理量计费（us-east-1 $0.30/h、$0.08/GB），跨 Region 另收传输费 M1；大吞吐时 DR 复制费可能很可观（100 MiB/s 约 $20.5k/月处理费，推导） | 未公开 |
解读：RPO = 0 意味着写入要在跨 Region 确认后才 ack，因此写延迟会包含一次跨 Region RTT。在拿到书面说明和 PoC 结果之前，这一宣称既不应否认，也不应视为已验证。
建议向 AutoMQ 提的问题：「RPO = 0」下 producer 的写延迟是多少？对 Region 间距离有何假设？需要哪个档位、价格多少？RTO ≈ 10s 的测量前提和故障场景是什么？
| 客户条件 | 倾向 | 依据 |
|---|---|---|
| 写 p99 必须 < 100 ms，且只考虑开源版 | MSK | §0 #1 |
| 写 p99 < 50 ms，可以买商业版 + FSx / EFS | 两者都可以 → 做同负载 PoC；FSx WAL 稳态 p99 7.6–15.9 ms，但故障停写 15–146 s（AWS 实测，测试记录 §10.3、§10.4、§10.5）；把 FSx / EFS 费用和 2-AZ HA 对的切换算进去 | §0 #9、#14；§4.1 |
| 写入 ≥ 数百 MB/s，扇出 ≤ 1–2，保留 ≥ 7 天，延迟容忍 ≥ 500 ms | AutoMQ 有真实成本优势；MSK 侧先开 follower fetching + 压缩 + tiered / Express 再比价 | §4.3.4–4.3.5 |
| 写入 ≈ 10 MiB/s 量级，且要毫秒级写入 | MSK（AutoMQ 在这一档的价格对应 S3 WAL 约 500 ms；按分区护栏重算后，AutoMQ 比 Standard + tiered 便宜约 10%，分区 ≤ 1,000 时 MSK 便宜约 16%） | §4.3.3 |
| 写入 ≈ 10 MiB/s 量级，能接受数百毫秒写延迟，分区数多 | AutoMQ 有成本优势（对 Express 约 44%、对 Standard + tiered 约 10%，推导，未实测） | §4.3.3 |
| 需要 Kafka 4.x 功能 / Strimzi 1.x | MSK | §0 #3 |
| 现网用 IAM 认证或要求 CMK | MSK | §0 #5、#6 |
| PCI / HIPAA / FedRAMP / GovCloud | MSK（AutoMQ 需要客户合规团队逐项确认） | §0 #24；§4.6 |
| 必须多云 | AutoMQ | §5.1 |
| 需要 Spot / RI 压计算成本 | AutoMQ | §5.1 |
| 入湖要 Upsert / CDC、Avro / Protobuf | AutoMQ Table Topic，或 MSK + Flink / Connect | §0 #28；§4.9 |
| 单分区热点 > 4 MBps 或保留 > 60 天（AutoMQ Cloud 文档范围） | MSK，或者先书面确认 AutoMQ BYOC 是否适用这些限制 | §0 #11 |
| 现在是 MSK ZooKeeper 集群，担心「反正要迁一次」 | MSK：2026-08-10 起支持原地 ZK→KRaft 迁移 M9（2AZ Standard 除外） | §6 Q4 |