AWS 官方称 Graviton 比同级 x86 性价比高 40%。讲清哪些负载迁了真省钱、哪些迁了会踩坑，以及迁移顺序。
AWS 官方在自己的 EC2 页面上是这么介绍自研芯片的：由基于 Arm 的 Graviton 处理器架构提供支持，与同级 x86 芯片架构相比，性价比提升了 40%。
但你去翻任何一篇「AWS 折扣全攻略」，都不会看到 Graviton —— 因为它不是折扣，没有承诺、没有期限、也没有兑换入口。它只是一种不同的实例类型。
问题是：对掏钱的人来说，换一颗芯片省下的钱，和买一份一年承诺省下的钱，是同一笔钱。 而前者没有锁定期，随时可以换回来。这篇就讲它值不值得做。还有一条顺序上的坑：承诺类折扣绑定实例族，换了架构会降低承诺覆盖率——所以是先定架构、再买承诺。五家的机制对比见 五家云厂商折扣机制对比。
它不在任何「折扣清单」里，却可能是最大的一笔
把各类省钱手段按「代价」排一下，就很清楚它的位置：
| 手段 | 省多少 | 代价 / 锁定期 |
|---|---|---|
| Spot 竞价实例 | 最高可低约九成（浮动） | 会被中断 |
| 预留实例 / 节省计划 | 承诺换折扣 | 锁 1 年或 3 年，买错难补救 |
| 换成 Graviton | 官方口径性价比最高 +40% | 无锁定期，改回 x86 只需换实例类型 |
| 清理闲置 / 存储分层 | 视浪费程度 | 无代价，随时可做 |
关键差别：预留实例和 Spot 都是在「为同一颗芯片讨价还价」，而 Graviton 换的是芯片本身。它不与前两者冲突——你可以同时享受「ARM 的低价」和「承诺的折扣」，因为它们作用在不同层面。
这也是为什么它值得单独写一篇：这是少数几个「不需要承诺、不需要承担中断风险」就能拿到的大幅省钱手段。
「性价比高 40%」这句话该怎么读
先给这句话做三个限定，否则一定会误判：
- 这是「性价比」，不是「价格」。 官方说的是 price-performance——即「单位性能的价格」更好，它可能来自单价更低，也可能来自同价性能更高。所以你的账单不一定直接少 40%，但跑同样的活，花的钱通常更少。
- 这是官方宣传口径，且是特定代际与对比对象下的数字。 不同代际（Graviton2/3/4）、不同实例族、不同负载，实测差异很大。不要拿 40% 去做预算，先自己压测。
- 它依赖你的负载能真的跑满 ARM。 如果迁移后因为某个依赖库没有 ARM 版本而性能退化，那省下的钱会被性能损失吃掉。
所以正确的读法是：这是一个值得做一轮实测的方向，不是一个可以直接写进预算的折扣率。
最低成本的验证方式：挑一个无状态、可随时回滚的服务（比如一台 Web 节点），换成同规格的 Graviton 实例，用真实流量跑一天，对比单位请求成本（总成本 ÷ 请求数），而不是只看实例单价。这个数字才对你的业务有意义。
四类迁了通常真省钱的负载
判断标准很简单：你的软件栈在 ARM 上是否有成熟、官方支持的构建。 有，就大概率省钱；没有，就先别动。按这个标准，以下四类通常都很合适。
| 负载类型 | 为什么适合 | 注意 |
|---|---|---|
| Web / 应用服务器 | Nginx、Node、Python、Java、Go、PHP 在 ARM 上都有官方构建 | 确认你用的运行时版本有 ARM 包 |
| 容器化微服务 | 镜像是自己在 CI 里构建的，改成多架构即可 | CI 需要支持构建 ARM 镜像（或交叉编译） |
| 缓存与中间件 | Redis、Memcached、Kafka 等主流组件都支持 ARM | 注意客户端驱动与监控 agent |
| 托管数据库（换实例族） | 部分托管数据库提供 Graviton 实例族选项 | 预留实例绑定实例族——换之前先看承诺怎么处理 |
- 共同点：都是自己可控构建的部分，或者厂商明确提供了 ARM 支持。
- 额外收益：ARM 实例的能效通常更好，在高密度部署（比如大量小容器）时，单位算力的成本优势会被放大。
从最无状态的那一层开始。 Web 层和容器 worker 是最容易验证、也最容易回滚的一层；它们的经验可以直接复用到后面更复杂的层。数据库虽然后台也能换，但不该是第一站。
实例族怎么选、同规格之间怎么比，写在 EC2 实例怎么选。
三类先别迁（或者迁不动）的情况
下面三类是迁移里最常见的事故来源。共同点是：问题不在芯片，而在依赖。
- 依赖闭源软件或专有 x86 指令。 某些商业软件、老版本的闭源 agent、加密/编解码库只提供 x86 二进制。这类在 ARM 上要么跑不起来、要么性能大幅退化。判断方法：先在一台 ARM 实例上完整跑一遍你的部署流程。
- 监控、安全与运维 agent 没有 ARM 版本。 这是最常被漏掉的一项——应用本身没问题，但监控 agent、APM、EDR 装不上，等于放弃可观测性。迁移前先列一份 agent 清单逐个确认。
- 机器学习/科学计算依赖特定加速库。 部分计算库在 ARM 上的版本与优化程度不同，需要逐个确认；如果依赖 GPU，那么瓶颈本来就不在 CPU 架构上，换 Graviton 的收益有限。
⛔ 一条容易踩的规则：Windows 实例不在 Graviton 的支持范围内。 如果你的业务依赖 Windows，这一节可以直接跳过——换成 ARM 这条路对你不适用，省钱要从预留实例、存储分层和清理闲置上找（见 AWS 折扣不只在 EC2）。
还有一类属于「能迁但不值得」：只在夜间跑几分钟、成本本来就极小的任务。迁移要投入构建、测试与灰度的时间，如果这项服务一个月的账单本来就很低，投入产出不划算。优先迁移账单占比高、形态稳定的那部分。
迁移顺序：一次只动一层
Graviton 迁移的风险不在技术难度，而在一次动太多。推荐按下面四步走，每一步都能独立回滚。
- 第一步：挑一台做对照。 选一个无状态、可摘除的节点，换成同规格 ARM 实例，用真实流量跑一段时间，记录单位请求成本与 P95 延迟两个指标。
- 第二步：补齐构建链。 在 CI 里产出多架构镜像（x86 + ARM 都要能构建），并保证发布流程可以同时管理两套。这一步没做完，不要开始批量切换。
- 第三步：灰度。 先把 10%–20% 的流量切到 ARM 节点，观察至少一个完整业务周期（含峰值时段），确认没有依赖缺失导致的问题。
- 第四步：逐步扩大，然后处理承诺。 比例稳定后再扩大；最后才去处理预留实例/节省计划——因为承诺绑定实例族，换架构会影响已有承诺的覆盖率。
| 阶段 | 成功标准 | 失败时 |
|---|---|---|
| 对照测试 | 单位请求成本下降，延迟不退化 | 直接换回 x86，成本为零 |
| 构建链 | 两套架构都能自动构建与发布 | 停在对照阶段，不扩大 |
| 灰度 | 一个业务周期内无异常 | 把流量切回 x86 节点 |
| 扩大 + 承诺调整 | 覆盖率与折扣符合预期 | 回退实例族，重新评估承诺 |
为什么强调「能独立回滚」：Graviton 迁移最常见的失败不是性能差，而是某个依赖在某个角落突然暴露。能一键回滚，这个风险就是可控的；不能回滚，它就变成一次事故。
五个真实的坑，以及绕开办法
按踩中概率排序，这五个是迁移里最常出问题的地方。
| 坑 | 表现 | 绕开办法 |
|---|---|---|
| 镜像/AMI 拿错了架构 | 实例起不来，或起来后跑的是模拟层导致性能极差 | 明确指定 ARM 镜像；启动后先确认架构与实例类型一致 |
| CI 只构建 x86 镜像 | 部署到 ARM 节点时拉不到镜像 | 先把 CI 改成多架构构建，再切节点 |
| 第三方 agent 缺 ARM 版 | 监控/安全/日志采集在部分节点上消失 | 迁移前列 agent 清单逐个确认，这是最常被漏的一项 |
| 预留实例不覆盖新实例族 | 换了架构，承诺覆盖率掉下去，账单反而涨 | 先看 AWS 预留实例怎么买 里关于实例族锁定的部分，再决定切换节奏 |
| 只比单价、不比单位请求成本 | 看着便宜了，实际吞吐下降导致总成本持平 | 用「总成本 ÷ 业务量」做对比，这是唯一有意义的指标 |
第四个坑值得单独说：预留实例（RI）是绑定实例族的。你买了 x86 实例族的三年承诺，然后迁到 Graviton，那份承诺并不会自动跟着走——覆盖率掉下来，账单可能不降反升。所以「先换架构还是先买承诺」有个明确顺序：先定架构，再买承诺。 反过来做，就要面对承诺浪费的问题（补救办法见 AWS 预留实例怎么买）。
一个更稳的组合：如果未来可能换架构，优先用计算类节省计划而不是预留实例——它不锁定实例族与区域，换到 Graviton 后承诺依然覆盖。代价是折扣通常略低于同条件 RI，换来的是架构自由。 对比见 节省计划与预留实例怎么选。
最后，Graviton 属于官方侧的省钱（降低 AWS 账单单价）。通过代理商开通与结算降低的是你实际支付的金额，两者在不同层面、可以叠加——见 AWS 折扣与代理定价。
常见问题
换 Graviton 真的能省 40% 吗？
不要这么理解。40% 是 AWS 官方对「Graviton 相对同级 x86 的性价比」的宣传口径（且针对特定代际与对比条件），它是单位性能的价格，不等于你的账单直接减少 40%。正确做法是自己做对照测试：挑一个服务换成 ARM，用「总成本 ÷ 业务量」对比，这个数字才对你的业务有意义。
需要改代码吗？
大多数情况下不需要改业务代码，但要改构建与部署：容器镜像要产出 ARM 版本（或做多架构镜像），启动镜像要选对应架构。真正需要改代码的情况通常只有两种——代码里写死了架构相关的依赖，或者用到了只提供 x86 二进制的闭源库。
Windows 能迁吗？
不能。Graviton 是 ARM 架构，Windows 实例不在其支持范围内。如果你的业务依赖 Windows，这条路不适用，应从预留实例、存储分层、清理闲置与代理渠道上找空间（见 AWS 折扣不只在 EC2）。
已经买了 x86 的预留实例，还能迁吗？
能迁，但要注意承诺不会跟着架构走——RI 绑定实例族，迁到 ARM 后原承诺的覆盖率会下降，账单可能不降反升。补救路径（转售 / 修改 / 吸收）与「分批买」的建议见 AWS 预留实例怎么买。如果早就打算换架构，当初更应该用计算类节省计划，见 节省计划与预留实例怎么选。
从哪一层开始迁最稳？
从无状态、可摘除、可一键回滚的那一层开始：Web 层或容器 worker。用真实流量做对照，看单位请求成本与 P95 延迟两个指标。数据库虽然也能换，但不该是第一站——它的回滚成本高得多。
它和 Spot、预留实例冲突吗？
不冲突，它们作用在不同层面：Graviton 改变的是你用哪种芯片（单价基线），预留实例/节省计划是在这个基线上再打折，Spot 则是用可中断性换更低价格。三者可以同时用：ARM 实例 + 预留折扣，弹性部分再走 ARM 的 Spot。见 AWS 折扣与代理定价。