運算核心與虛擬化進化：從 EC2、Nitro 到 Graviton 自研晶片

EC2 看起來是一個老題目，實際上底下這幾年換過兩次核心：虛擬化被搬離主機 CPU，處理器則多了一條 AWS 自己設計的 Arm 路線。

這篇把 Nitro 的卸載架構、Graviton 的評估方式，以及 Auto Scaling 與 Spot 的成本紀律講清楚，全部從系統工程師與 SRE 實際會碰到的角度切入。

先把 EC2 想成資源，不是一台機器

EC2 給你的確實是一台虛擬機，但正確的心智模型是：一份可以隨時開、隨時關、隨時換掉的運算資源。

SRE 的許多痛苦，都來自於還把它當成機房裡那台有名字的實體伺服器。名字一取，就捨不得砍了。

這個轉換不是修辭。後面談的 Auto Scaling 與 Spot，前提都是同一句話：這台不見了也沒關係。

Nitro：把虛擬化搬離主機 CPU

傳統虛擬化裡，hypervisor 要負責 CPU、記憶體、網路與儲存的管理，這些工作全部吃主機的資源。你付了一整台機器的錢，其中一塊被管理層拿走。

Nitro 的做法是拆開。官方把它分成幾個元件，把輸入輸出與安全功能卸載到專用硬體上，讓 hypervisor 只留下最小的那一塊職責。

2026 年 6 月，AWS 宣布 Graviton5 的 M9g 系列正式推出，官方說明提到這批執行個體建立在第六代 Nitro System 之上，並首次納入 Nitro Isolation Engine。

官方對這個元件的說法是採用形式驗證，以數學證明的方式確保它的行為與定義完全一致。對需要說明隔離機制的稽核場合，這是值得記下的一句敘述，細節仍以官方文件為準。

Graviton：Arm 進資料中心之後的實務問題

Graviton 是 AWS 自研的 Arm 架構處理器。對使用者來說重點不是它是誰做的，而是同一個工作負載換過去之後，帳單與延遲會怎麼變。

2026 年的現況是：官方於 2026 年 6 月 10 日宣布 Graviton5 正式推出，首波是通用型的 M9g 與帶本機 NVMe 儲存的 M9gd。推出時的可用 Region 有限，實際供應情形以官方頁面為準。

至於性價比，AWS Graviton 產品頁（2026 年 8 月查閱）的說法是，Graviton 執行個體的成本最多比同等的 x86 執行個體低 20%。請注意那是官方的上限敘述，不是你一定會拿到的數字。

換不換得過去，實務上只看三件事。

• 執行環境有沒有 arm64 版本。跑在 JVM、Go、Python、Node.js 上的服務通常最輕鬆，但容器映像也必須有 arm64 版本。
• 有沒有夾帶原生相依。JNI、C 擴充套件、預先編譯好的二進位檔，是最常見的卡點。
• 有沒有事先講好的比較基準。搬過去要跟原本比什麼指標，開工前就要定，不然事後只會吵感覺。

成本控制的三層：規格、數量、價格模式

運算成本的問題幾乎都能拆成三個：規格對不對、數量對不對、用哪一種價格模式買。三層要分開處理，混在一起就會做出奇怪的決定。

規格層要靠量測。長期 CPU 使用率只有個位數百分比的執行個體，換晶片架構省下的錢，遠不如把規格改小來得多。

數量層交給 Auto Scaling。官方文件把調整容量的方式分成手動、排程、動態與預測性幾類，各自對應不同的流量形狀。

• 排程調整：適合可預期的作息型流量，例如上班日早上的固定尖峰。
• 動態調整：跟著 CloudWatch 指標走，其中目標追蹤最常用，也最不容易調壞。
• 預測性調整：依歷史模式預先擴充，補的是動態調整反應不及的那段暖機時間。

另外別忘了 Auto Scaling 的另一半用途。官方文件特別提到，它也很適合用來維持固定數量的伺服器：壞掉一台自動補一台，這件事本身就有價值。

Spot：拿折扣，同時準備好被收回

Spot 用的是閒置容量。官方頁面（2026 年 8 月查閱）的說法是相較隨需價格最多可省下 90%，代價是 EC2 需要容量的時候會把執行個體收回去。

官方文件把收回的原因分成容量、價格與限制條件三類。特別要留意的是：如果你設了最高出價，中斷會比不設更頻繁。

中斷通知會在停止或終止前兩分鐘發出，同時出現在 EventBridge 事件與執行個體中繼資料裡。官方建議每五秒檢查一次，並註明通知是盡力而為。

TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -sH "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/spot/instance-action

換句話說，兩分鐘的緩衝是拿來善後的：從負載平衡器上摘掉、把處理中的工作退回佇列、把日誌送出去。不要指望在這兩分鐘裡完成一次完整的資料收尾。

要把中斷的痛感壓低，做法其實很固定。

• 型別要夠雜。同一種型別被整批收回的機率，遠高於分散在多個容量池；官方的屬性式型別選擇就是為了讓你不必手動維護清單。
• 可用區也要分散。型別乘上可用區，才是你實際擁有的容量池數量。
• 選對配置策略。以容量為導向的策略會挑目前容量最充裕的池，中斷率通常比純挑最便宜的低。
• 混合購買模式。基準流量用隨需或承諾型方案，尖峰的彈性部分才交給 Spot。

一個務實的推進順序

1. 先量測，把長期低使用率的執行個體找出來，在規格層先省一次。
2. 把無狀態服務放進 Auto Scaling 群組，並實際驗證它真的會自動補一台回來。
3. 挑一個好回滾的服務試 Graviton，用同一份監控指標對照。
4. 最後才引入 Spot，而且從最不關鍵的那一批開始。

順序反過來做通常會很痛。在還沒有自動復原能力的架構上導入 Spot，等於替自己安排了一場沒有預告的故障演練。