AWS 云计算：全球第一的光环下，藏着怎样的真相
AWS 云计算：全球第一的光环下，藏着怎样的真相？
AWS 是全球云计算市场占有率第一的厂商，这一地位已持续十余年。但”第一”是否等于”最好”？当我们抛开品牌光环，从架构设计、工程实践、性能数据、价格四个维度进行实测和分析后，得出的结论可能会颠覆很多人的认知。
本文所有结论均基于一手测试数据和抓包分析，不做任何主观外推。
一、设计理念：高可用的代价，用户买单
1.1 强制跨可用区：每次写入都要跨机房
AWS 的 RDS MySQL 默认部署模式是 Multi-AZ（多可用区），主备实例强制分布在不同的可用区。这一设计的出发点是高可用——单个机房故障时可以自动切换。
但代价是什么？
每一次写操作，至少需要跨可用区 2-3 次：
- 应用写入主库 → 跨 AZ 写入云盘（EBS 通过网络落盘）
- 半同步复制 → 跨 AZ 将 binlog 发送到备库
- 备库确认收到 → 跨 AZ 返回 ACK
实测 AWS 可用区间 RTT 约 0.75ms 。这意味着仅网络延迟这一项，每次写操作就要额外付出 1.5~2.25ms 的开销。
实际业务体感：
- AWS 上一次最简单的 INSERT：3.32ms（业务实测）
- 同样的业务在 IDC 物理机：微秒级（0.x ms）
差距不是百分之几十，而是 数倍到一个数量级 。
1.2 对比：阿里云的灵活选择
阿里云 RDS 提供集群模式，允许将 2 个节点部署在同一可用区，在对延迟极度敏感的场景下实现接近 IDC 的性能。用户可以根据自身业务特点在”极致高可用”和”极致低延迟”之间做选择。
AWS 和华为云目前不提供这种灵活性，用户被强制接受跨 AZ 的延迟开销。
1.3 云盘延迟：贵不等于快
AWS 的 EBS 云盘走网络存储，延迟远高于本地盘。实测数据（fio 4K 随机读写，iodepth=1）：
| 云盘类型 | 读延迟 | 写延迟 |
|---|---|---|
| AWS io2（最贵） | 393 us | 306 us |
| AWS io1 | 588 us | 868 us |
| AWS gp3 | 686 us | 994 us |
gp3 写延迟接近 1ms ，而阿里云 ESSD 在同等场景下可以做到 0.1~0.2ms 级别。AWS 最高档的 io2 写延迟（306us）仍然是阿里云高性能云盘的 2-3 倍 。
对于数据库这种对 IO 延迟极度敏感的负载，这意味着每一个 commit 都在额外等待。
二、工程实践：350 秒连接静默丢弃事件
如果说设计理念的问题还可以归结为”理念之争”，那么以下这个事件则暴露了 AWS 在工程实践和事故响应上的严重问题。
2.1 问题现象
业务迁移到 AWS 第 8 代实例（M8/C8/R8，Nitrov6 架构）后，Java 服务每隔 20~30 分钟出现批量连接超时：
1 | Connection is not available; request timed out after 5006ms |
网络延迟稳定在 ~8ms，0% 丢包，MySQL 健康。
2.2 根因：ENI 连接跟踪超时从 5 天骤降至 350 秒
通过 80 分钟、84595 个包的系统性抓包分析，定位到根因：
AWS 第 8 代实例的 ENI（弹性网卡）安全组连接跟踪，将 TCP Established 默认超时从 432000 秒（5 天）悄然改为 350 秒。
| 实例代次 | Nitro 版本 | TCP Established 默认超时 |
|---|---|---|
| 第 7 代及以下 | Nitrov5 及以下 | 432000s（5 天） |
| 第 8 代（M8/C8/R8） | Nitrov6 | 350s |
这是一个 1234 倍的缩减 ，且行为极为恶劣——超时后 ENI 静默丢弃数据包，不发送 RST，不通知任何一方。抓包中 84595 个包 0 个 RST 。
客户端和服务端都以为对方还在，TCP 连接变成”僵尸”——直到下次使用时才发现已死，此时应用只能等待重传超时（数十秒到数分钟），表现为”突然卡住然后超时”。
2.3 AWS 的事故复盘令人失望
这一事件中 AWS 的表现：
文档滞后：用户 4 月初碰到问题，4 月 7 日定位到中间设备释放连接，4 月 15 日还在抓包验证。而 AWS 直到 4 月 11 日才在文档中加入警告段（通过 Wayback Machine 快照对比确认）
变更未通知：从 432000s 改到 350s 这种破坏性变更，C8gn GA 公告（2025-06）中未提及超时变更。用户升级实例后莫名遇到连接问题，排查成本极高
比 NAT Gateway 更”哑”：
- NAT Gateway / NLB 超时后至少一侧会收到 RST，应用能感知”对端断了”
- ENI conntrack 超时：双侧都收不到 RST ，包被静默丢弃，应用只能靠 OS 重传超时来发现
复盘质量：AWS 官方的事件复盘未能清晰阐述根因，定位路径模糊
2.4 “350 秒”——AWS 的系统性问题
350 秒这个数字在 AWS 生态中反复出现：
| 组件 | 空闲超时 | 超时后行为 |
|---|---|---|
| NAT Gateway | 350s（固定） | 发 RST |
| NLB（2024-09 前） | 350s（固定） | 发 RST |
| GWLB | 350s | 发 RST |
| ENI Conntrack（Nitrov6） | 350s（默认） | 静默丢弃 |
社区早在 2021 年就有人踩坑（Paramount Tech Blog），2022 年 DBA 博客记录了 JDBC 挂起问题，2023 年 urllib3 专门开了 Issue。这不是新问题，但 AWS 在 ENI 层面重蹈覆辙，且行为更恶劣（不发 RST）。
三、性能数据：Sysbench 实测全面落后
以下数据来自 10 个环境的标准化 Sysbench 测试，使用 16 表 x 1000 万行（约 50GB 数据），MySQL Buffer Pool 16GB，故意制造 IO 压力以考验真实磁盘性能。
3.1 只写场景（oltp_write_only）—— 单线程 QPS
这是最能体现”每次写操作延迟”的场景：
| 环境 | 1 线程 QPS | 对比 IDC |
|---|---|---|
| IDC（物理机） | 19,282 | 基准 |
| IDC（trx1） | 15,367 | 80% |
| 阿里云 | 12,484 | 65% |
| 阿里云（trx1+repl） | 5,832 | 30% |
| AWS io2 | 8,881 | 46% |
| AWS io2（trx1） | 3,575 | 19% |
| AWS gp3 | 1,689 | 9% |
AWS gp3 单线程写入性能仅为 IDC 的 9%，仅为阿里云的 14%。 即使用最贵的 io2 云盘（价格是 gp3 的数倍），开启 trx1 后也只有 IDC 的 19%。
3.2 读写混合场景（oltp_read_write）—— 64 线程 QPS
| 环境 | 64 线程 QPS | 对比阿里云 |
|---|---|---|
| 阿里云 | 83,569 | 基准 |
| IDC | 69,255 | 83% |
| AWS io2 | 51,002 | 61% |
| AWS gp3 | 64,869 | 78% |
3.3 点查询场景（oltp_point_select）—— 64 线程 QPS
| 环境 | 64 线程 QPS | 对比阿里云 |
|---|---|---|
| 阿里云 | 328,098 | 基准 |
| IDC | 299,555 | 91% |
| AWS io2 | 157,480 | 48% |
| AWS gp3 | 228,321 | 70% |
AWS io2 在纯读场景下也只有阿里云的 48% ，令人诧异。
3.4 延迟对比（95 分位，单线程）
| 场景 | IDC | 阿里云 | AWS io2 | AWS gp3 |
|---|---|---|---|---|
| 点查询 | 0.04ms | 0.07ms | 0.09ms | 0.67ms |
| 只写 | 0.52ms | 0.99ms | 1.61ms | 5.99ms |
| 读写混合 | 2.81ms | 3.30ms | 3.89ms | 15.00ms |
AWS gp3 的只写延迟是 IDC 的 11.5 倍，是阿里云的 6 倍。
3.5 小结
即便使用 AWS 最贵的 io2 云盘（2T 云盘价格是 8C32G 机器的 8 倍），性能仍然大幅落后于阿里云使用普通云盘的配置。云盘延迟是 AWS 数据库性能的致命瓶颈。
四、价格：花更多的钱，买更差的性能
4.1 AWS RDS MySQL 成本
以 16C64G、GP3 2TB 20000 IOPS、3 节点（1 主 1 Multi-AZ 备 1 只读副本）为例：
Intel（db.m5d.4xlarge）：
- 计算：¥204,964/年（折后）
- 存储（GP3 2TB x3）：¥83,589/年（折后）
- 监控（CloudWatch）：¥25,713/年（折后）
- 合计：约 ¥314,266/年
ARM（db.m6gd.4xlarge）：
- 计算：¥183,718/年（折后）
- 存储：¥83,589/年（折后）
- 合计：约 ¥267,307/年（不含监控）
最新一代 Intel（m7i.4xlarge，ap-southeast-1）：价格更高。
4.2 性价比对比
| 维度 | AWS（io2，最贵） | AWS（gp3） | 阿里云 |
|---|---|---|---|
| 只写 64 线程 QPS | 79,754 | 43,519 | 110,923 |
| 读写混合 64 线程 QPS | 51,002 | 64,869 | 83,569 |
| 云盘写延迟（iodepth=1） | 306 us | 994 us | ~100-200 us |
| 价格档位 | 极高 | 高 | 中 |
AWS 用最贵的云盘（io2），花了最多的钱，性能仍然不如阿里云用普通云盘。
io2 的 2T 云盘年费约为同规格机器的 8 倍——付出如此高昂的代价，换来的却是垫底的性能表现。
4.3 隐性成本
除了直接的资源费用，AWS 还有大量隐性成本：
- 排障成本：350 秒静默丢连接这种问题，排查周期以周计，需要系统性抓包分析
- 架构妥协成本：被迫跨 AZ 部署，无法选择同 AZ 低延迟模式
- 升级风险成本：实例升代时默认行为发生破坏性变更，无事先通知
- 学习曲线成本：需要深入了解 ENI 连接跟踪、NAT Gateway 固定超时等独有”坑点”
五、结论：惯性认知 vs 客观事实
AWS 能成为全球第一，有其历史原因：起步最早（2006 年）、生态最完善、全球覆盖最广。但”市场占有率第一”不等于”技术最优”，更不等于”性价比最高”。
从本文的实测数据来看：
| 维度 | 表现 |
|---|---|
| 设计理念 | 强制跨 AZ，牺牲延迟换高可用，不给用户选择权 |
| 工程实践 | 350s 超时静默丢包，变更不通知，复盘不透明 |
| 性能 | 全场景 Sysbench 垫底，gp3 只写仅为 IDC 的 9% |
| 价格 | 同等配置显著高于竞品，io2 价格是机器的 8 倍 |
| 性价比 | 花最多的钱，得到最差的性能 |
很多企业选择 AWS 的原因是”大家都在用””全球第一应该不会错”——这是典型的幸存者偏差和品牌惯性。当我们真正用数据说话时，会发现这个”全球第一”的光环，更多是依靠先发优势和生态锁定维持的，而非技术和性价比的领先。
对于数据库这类对延迟和 IO 性能极度敏感的工作负载，在有选择的情况下，AWS 恐怕是最不应该选的那一个。
注：本文所有性能数据均来自实际测试环境，测试工具为 sysbench，测试代码开源。网络分析基于 84595 个包的系统性抓包。价格数据来自官方控制台和报价器。文档变更时间线通过 Wayback Machine 快照验证。