AWS ECS Managed Instances 推出跨執行個體與 Spot 整併：容器費用怎麼省、上線前要檢查什麼
在 AWS 上跑容器的企業，常遇到一個看不太到、卻每個月都在付錢的問題：主機開了很多台，但每台都只用了一半。 流量下降、任務縮減之後，任務零散地留在各台 EC2 上，沒有一台能關掉。
AWS 在 2026 年 10 月 28 日宣布，Amazon ECS Managed Instances 新增「跨執行個體整併」與「Spot 整併」兩項功能，會自動把低使用率主機上的任務重新集中到較少的主機，不需另外設定、不另收費。這篇文章整理官方重點，並說明企業在功能自動生效前後，應該檢查哪些設定。
新聞重點：AWS 宣布了什麼
以下內容整理自 AWS What's New 公告與 ECS 開發者文件（查核日期：2026-10-30）。
兩項新功能
跨執行個體整併（cross-instance consolidation）：同時評估多台低使用率的執行個體，把任務重新打包到較少的主機上。過去 ECS 是一台一台分別評估，當容量提供者只設定少數幾種執行個體類型時，能省下的空間有限。
Spot 整併（Spot consolidation）：把同樣的做法套用到 Spot 執行個體，並會先確認有可用的替代容量，才進行整併。
兩者都沿用 ECS 既有的「先啟動、再停止」（start-before-stop）任務替換方式。
適用範圍與費用
適用所有 AWS 區域，不另外收費。
自動套用到所有既有與新建的 ECS Managed Instances 容量提供者（capacity provider）。
AWS 公布的測試數據
AWS 在公告中提供一組測試：容量提供者設定為 c9g 執行個體（最小 4xlarge），執行 261 個任務（每個 1 vCPU、1.94 GiB 記憶體）。整併後執行個體從 19 台降到 13 台，CPU 使用率從 42% 提高到 91%，記憶體使用率從 41% 提高到 88%。
這是 AWS 的單一測試情境，實際效果會依任務大小、執行個體類型與流量模式而不同。
先認識 ECS Managed Instances
ECS Managed Instances 是 ECS 的一種全代管運算選項。依 AWS 官方說明：
執行個體的佈建、設定、工作負載配置、修補、擴展與維護由 AWS 處理，運算資源仍位於客戶自己的 AWS 帳號內。
安全修補以每 14 天為週期進行，可用 EC2 事件時段（event windows）安排在每週維護時段。
與 Fargate 相比，可以選擇 GPU、網路最佳化等特定執行個體類型，也支援特權容器。
可用區域：所有 AWS 區域，但不含 AWS GovCloud（US）與中國區域。
計費方式
費用項目 | 說明（依 AWS 官方定價頁） |
|---|---|
EC2 執行個體費用 | 依 ECS Managed Instances 啟動的執行個體類型與時間計費，每秒計費、最少 1 分鐘 |
ECS Managed Instances 費用 | 在 EC2 費用之外另計，依執行個體計費，不依任務數 |
可搭配的購買方式 | On-Demand、1 年／3 年 Reserved Instances、Compute Savings Plans、Spot（適用於 EC2 部分） |
購買方式對管理費用的影響 | ECS Managed Instances 費用與 EC2 購買方式無關 |
實際單價請以 AWS 官方定價頁與 AWS Pricing Calculator 為準。由於費用依執行個體計算，主機數量減少，EC2 費用和 ECS Managed Instances 費用都會跟著下降，這也是這次整併功能對成本的直接意義。
整併是怎麼運作的
依 ECS 開發者文件，基礎架構最佳化包含兩種偵測：
閒置執行個體：最後一個任務停止後，ECS 將執行個體標記為 DEREGISTERING，再安全終止底層 EC2。
低使用率執行個體：ECS 先把執行個體標記為 DRAINING，用任務替換把工作負載移到其他主機，全部移完後再標記為 DEREGISTERING 並清除。
文件也列出幾個重要的保護條件：
只處理 service 任務，不會替換獨立執行的 standalone 任務。
遵守服務的最小與最大任務數限制。
保留任務保護（task protection）設定。
可用容量提供者的 ScaleInAfter 參數調整開始最佳化前的等待時間：0 到 3600 秒；設為 -1 代表停用；不設定則由 ECS 自動決定。
注意： 查核當下，ECS 開發者文件仍寫著「低使用率整併不支援 Spot 執行個體」，與 10-28 公告新增的 Spot 整併不一致，可能是文件尚未更新。使用 Spot 的企業，建議以實際行為與後續文件更新為準。
企業影響與適用情境
以下為 WeWinCloud 的分析與建議，非官方說法。
誰最有感
白天與夜間流量落差大、會自動縮減任務數的電商與 SaaS 服務。
執行個體類型選擇較窄（例如只用單一系列、較大規格）的容量提供者，過去最難整併。
混用 Spot 降低成本、但常留下零散低使用率 Spot 主機的團隊。
可能的副作用
任務會被搬移。 整併代表任務會在主機之間重新啟動。應用程式若無法正常處理停止訊號、啟動很慢或依賴本機狀態，可能出現短暫錯誤。
主機餘裕變小。 使用率從四成提高到九成，代表突發流量時可用空間變少，擴展速度要更依賴自動擴展設定。
長時間工作要保護。 批次或長時間處理的任務，應使用任務保護，或改為 standalone 任務，避免被中途替換。
上線前的 6 項檢查
1. 盤點哪些服務在 Managed Instances 上
確認哪些 ECS 服務使用 Managed Instances 容量提供者，哪些是 EC2 或 Fargate。新功能只影響 Managed Instances。
2. 檢查優雅停止
確認應用程式能正確處理 SIGTERM、在 stopTimeout 時間內完成收尾，並搭配負載平衡器的連線排空，讓任務替換時不中斷使用者連線。
3. 檢查健康檢查與部署設定
確認健康檢查能準確判斷新任務是否就緒，minimumHealthyPercent 與 maximumPercent 的設定，能讓替換期間仍維持足夠的任務數。
4. 為關鍵工作設定任務保護
批次、匯出、長時間連線的工作，評估是否開啟任務保護。
5. 調整 ScaleInAfter
流量波動頻繁的服務，可以拉長 ScaleInAfter，避免主機剛縮減又要擴展；若暫時不想啟用，可設為 -1。
6. 重新檢視 Savings Plans 與 RI 承諾
主機數量下降後，原本的 Compute Savings Plans 或 Reserved Instances 承諾量可能偏高。建議觀察 2 到 4 週的實際用量後，再調整下一期的採購。
常見問題 FAQ
這項功能需要手動開啟嗎？
不需要。依 AWS 公告，功能自動套用到所有既有與新建的 ECS Managed Instances 容量提供者。若要停用，可將 ScaleInAfter 設為 -1。
會額外收費嗎？
依 AWS 公告不另收費。ECS Managed Instances 本身仍會在 EC2 費用之外另計管理費用。
使用 Fargate 或一般 ECS on EC2 會受影響嗎？
這次公告針對 ECS Managed Instances 容量提供者，不影響 Fargate 或自行管理的 ECS on EC2。
整併會不會造成服務中斷？
ECS 採用先啟動、再停止的替換方式，並遵守服務最小任務數。但應用程式本身仍需能正確處理停止與啟動，建議先在測試環境觀察。
WeWinCloud 能提供什麼協助
WeWinCloud 提供雲端成本優化服務，包含帳單健檢與分析、RI / SP 採購策略、資源調整與閒置優化、持續監控與成本報告，也提供系統架構設計、高可用與備援架構等架構規劃服務。
如果你的團隊正在評估 ECS、Fargate 或 Kubernetes 的成本差異，或想確認容器服務能安全承受自動整併，可以先和我們聊聊實際架構。
想檢查 AWS 容器服務的成本與架構？👉 與我們聯繫，由專人協助評估。
延伸閱讀
參考資料
留言