Spot 最高能省九成，但會被回收。講清兩分鐘中斷機制、四類能用與三類不能用的場景，以及混合部署怎麼配。
幾乎所有 AWS 折扣文章講到 Spot（競價實例）時都只有一句話：利用閒置資源，成本最高可降 90%，但需注意資源供應的穩定性。
這句話沒有錯，但它缺了最關鍵的兩個半截：90% 是怎麼來的（什麼條件下能到這個幅度），以及中斷到底怎麼發生（會提前多久、能不能優雅收尾）。不知道這兩點，你既不敢用，也不知道該怎麼用。
本文把這兩件事講透，並給出四類適合與三類絕不能放的判斷清單。閒置算力這一層五家都有，差別在中斷通知時長與折扣幅度，橫向對比見 五家雲廠商折扣機制對比。
「最高省九成」這句話缺了哪兩個半截
第一個半截：幅度是浮動的，而且是別人定的。 Spot 的價格由各區域、各實例型別的供需實時決定，不是固定折扣。官方口徑裡「最高可低約九成」是觀察到的上限，不是你能拿到的保證。熱門實例型別在緊張時段可能只有很小的折扣。
第二個半截：你付出的不是錢，是確定性。 按需實例貴在「隨時都有」；Spot 便宜在「隨時可能被收回」。所以 Spot 的折扣本質是中斷風險的定價，理解這點之後，剩下的問題就變成：你的工作負載能承受多大中斷風險。
| 維度 | 按需（On-Demand） | 預留 / 節省計劃 | Spot |
|---|---|---|---|
| 單價 | 最高 | 中等（承諾換折扣） | 最低（區間大，最高可低約九成） |
| 會不會被中斷 | 不會 | 不會 | 會，提前約兩分鐘通知 |
| 需要承諾嗎 | 不需要 | 需要（1 年或 3 年） | 不需要 |
| 適合什麼 | 不確定、臨時、不能中斷 | 穩態基線 | 可中斷、可重試的算力 |
一句話定位：預留實例和節省計劃是「承諾換便宜」，Spot 是「認了風險換便宜」。兩者不衝突，甚至應該同時用——先用承諾覆蓋穩態基線，剩下的彈性部分交給 Spot。
Spot 到底是什麼：不是打折的 EC2，是別人的退貨視窗
把 Spot 理解成「打折的 EC2」會誤導判斷。更準確的類比是：某個區域的 AWS 容量池裡，暫時沒人要的那部分算力，被拿出來按供需定價出售。 一旦有出價更高、或按需/預留的需求出現，這部分容量會被收回。
由此產生的三條性質，決定了它的用法：
- 價格隨供需波動。 同一個實例型別，不同區域、不同時段價格可能差很多。選冷門實例型別、多區域分散，往往能同時拿到更低價格和更低的中斷率。
- 容量不保證。 你想開 100 臺，可能只拿到 70 臺。請求本身可能部分失敗。
- 中斷是設計的一部分，不是故障。 它不是「偶爾出問題」，而是這套機制的正常行為——設計系統時必須預設它會發生。
因此 Spot 的使用前提是「工作負載可以被打斷」，而不是「希望它別被打斷」。這是絕大多數誤用的根源：把一個不能中斷的服務放上 Spot，然後祈禱它別被回收。
中斷是怎麼發生的：兩分鐘通知與三種回收原因
Spot 被回收時，AWS 會提前約兩分鐘發出中斷通知（歷史上是兩分鐘，具體以官方文件為準）。這兩分鐘是你能做的全部收尾時間，用法見本節末尾。
觸發回收大致有幾種情況，理解它們有助於選對配置：
| 觸發原因 | 含義 | 能做什麼 |
|---|---|---|
| 容量需求上升 | 有更高優先順序的需求要佔用這部分容量 | 換實例型別或換可用區；多型別分散可顯著降低命中率 |
| 價格超過你的最高出價 | 當前 Spot 價高於你設的上限 | 合理設定上限（很多場景設為按需價即可，仍能拿到折扣） |
| 實例型別/池容量枯竭 | 該容量池短期沒有可分配的量 | 多可用區 + 多實例型別是最有效的應對 |
兩分鐘該做哪三件事（按優先順序）：① 停止接收新請求（從負載均衡裡摘掉）；② 把進度寫到外部儲存（檢查點 / 訊息佇列回退）；③ 跑完手上的這批或主動放棄。這三件事要提前寫進應用邏輯，中斷時沒有時間做決策。
還有一條常被忽略的：中斷不代表工作白做。 把任務設計成「小分片 + 可重試 + 冪等」，一次中斷只損失一個分片，而不是整批。這是讓 Spot 真正可用的工程前提，比選哪個實例型別重要得多。
四類適合 Spot 的工作負載
判斷標準只有一條：中斷之後，重新跑一遍的代價是否可接受。 代價越小越適合。按這個標準，以下四類通常都合適。
| 型別 | 例子 | 為什麼適合 |
|---|---|---|
| 批處理 / 離線計算 | 日誌分析、報表生成、ETL、影片轉碼 | 任務可分片、可重試，中斷只影響當前分片 |
| CI/CD 與測試 | 編譯、自動化測試、壓測 | 天然短生命週期，跑完即棄，斷了重跑即可 |
| 無狀態彈性算力 | 可隨時擴縮的 Web 層、佇列消費者 | 節點消失時請求會被重新排程到其他節點 |
| 可容錯的訓練 / 渲染 | 帶檢查點的模型訓練、渲染農場 | 有檢查點就能斷點續跑，損失可控 |
- 共同點：都不依賴「這臺機器必須一直在」。
- 一個可量化的判斷：如果一次中斷的平均損失 < 折扣省下的錢的 5%–10%，就可以放心用。
最容易被低估的一類是無狀態 Web 層。 很多人只把 Spot 用在批處理上，其實「一部分固定容量（預留/按需）+ 一部分 Spot 彈性容量」的組合，對有明顯波峰的 Web 服務價效比極高——峰值用便宜的 Spot 扛，基線用承諾價扛。
具體的實例選擇與容量規劃見 EC2 實例怎麼選。
三類絕對不要放上 Spot 的東西
下面三類是真實的踩坑高發區。它們的共同點是中斷會造成資料損失或對外可見的故障，而不是「慢一點」。
- 有狀態資料庫的主節點。 資料庫被回收意味著寫盤中段、主從關係需要重建。即使有副本，主節點被打斷也會觸發故障切換，代價遠大於省下的錢。資料庫的成本問題應該用預留實例或儲存層最佳化解決，見 AWS 折扣不只在 EC2。
- 沒有外部狀態、又不能重跑的服務。 比如把會話、臨時檔案、中間結果放在本機磁碟的服務——機器一回收，資料就沒了。判斷標準：本機磁碟上有沒有「丟了就得從頭來」的東西。
- 有硬性交付時窗的任務。 必須在某個時間點前完成、且重跑來不及的任務（如結算截止前的批處理）。Spot 的中斷不可預測，不能賭。
⛔ 一個常被忽略的中間地帶：「可以中斷，但中斷後需要人工介入」的任務。這類不要放 Spot——省下的錢會被運維成本吃掉。能自動重試才叫可中斷，需要人來處理就不叫。
還有一類邊界情況值得單獨提：長期執行的、有對外 SLA 的服務，即使它是無狀態的。如果 Spot 大面積回收導致容量不足、響應變慢，那也是 SLA 事故。這類服務的基線部分應該用預留/按需保證，Spot 只作為峰值的補充。
怎麼用才穩：多實例型別 + 多可用區 + 混合底座
Spot 的穩定性不是靠「選對實例」，而是靠分散。三個動作按有效性排序：
- 多實例型別。 不要只請求一種實例，請求一組算力相近的型別。這樣某個池緊張時會自動落到其他池，中斷率通常顯著下降。
- 多可用區。 把請求分散到同區域的多個可用區，單個 AZ 的容量波動不會打垮整體。
- 混合底座（Mixed instances policy）。 在自動伸縮組裡同時配置按需/預留的基線容量 + Spot 的彈性部分。基線保證下限，Spot 吃彈性——這是生產環境最穩的形態。
| 組合方式 | 適用 | 風險 |
|---|---|---|
| 純 Spot | 內部工具、純離線任務 | 中斷影響全部容量，只適合可完全重跑 |
| 按需基線 + Spot 彈性 | 生產服務的主流形態 | 基線保底，彈性部分中斷只影響峰值能力 |
| 預留基線 + Spot 彈性 | 穩態明顯、且有波峰的業務 | 最省錢，但需要準確估算基線（見預留實例那篇） |
分配策略也值得一說：容量最佳化（capacity-optimized）類的策略會優先從當前最不容易被回收的容量池分配，通常比「選最便宜的池」更穩——因為最便宜的池往往正是最緊張的池。別隻盯價格選池。
與承諾折扣的關係：Spot 用量不在預留實例和節省計劃的覆蓋範圍內（那兩者覆蓋的是按需類的計算用量）。所以它們不衝突，而是分工：穩態走承諾、彈性走 Spot。
預留實例怎麼買（買多少、買幾年、買錯怎麼辦）寫在 AWS 預留實例怎麼買；兩條省錢路徑怎麼疊加見 AWS 折扣與代理定價。
常見問題
Spot 真的能省 90% 嗎？
「最高可低約九成」是官方口徑裡的觀察上限，不是保證值。實際折扣隨實例型別、區域、時段大幅波動——熱門型別在緊張時段可能只有很小的折扣。判斷時不要按 90% 算收益，按你實際拿到的價格算；選冷門實例型別、多區域分散通常能同時改善價格與中斷率。
提前多久通知？兩分鐘夠做什麼？
約兩分鐘（具體以官方文件為準）。夠做三件事：從負載均衡摘掉不再接新請求、把進度寫進外部儲存、把手上的分片跑完或主動放棄。前提是這個邏輯提前寫好了——中斷時沒有時間做決策或人工介入。
資料庫能放 Spot 上嗎？
主節點不建議。被回收意味著寫盤中段與故障切換，代價遠超省下的錢。有副本也不改變這個結論——故障切換本身就是一次事故。資料庫成本應從預留實例、儲存層選型與讀寫分離上解決，見 AWS 折扣不只在 EC2。只讀副本、分析型從庫在部分場景下可以考慮，但同樣要把「重跑代價」算清楚。
怎麼降低被回收的機率？
靠分散，不是靠挑實例：請求一組算力相近的實例型別而不是一種、跨多個可用區請求、並用「容量最佳化」類的分配策略（優先從當前不容易被回收的池分配，而不是最便宜的池）。這三條比任何單個引數都有效。
Spot 和節省計劃能一起用嗎？
它們不衝突，因為覆蓋的是不同用量：節省計劃覆蓋按需類的計算用量，Spot 用量不在其覆蓋範圍內。所以合理分工是：穩態基線走預留實例/節省計劃，彈性部分走 Spot。把兩者當成二選一是常見誤解。
生產環境敢用 Spot 嗎？
敢，但要用混合底座：用按需或預留保證基線容量，Spot 只承擔超出基線的彈性部分。這樣即使 Spot 全被回收，服務仍有基線容量可用，只是峰值能力下降。純 Spot 跑生產服務只在「可完全重跑、無 SLA」的場景下才合適。