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 折扣與代理定價。