企業級容器治理：EKS 與 ECS 的叢集管理與部署流水線

「我們該用 EKS 還是 ECS」這個問題，我看過太多次被拿去比功能表。比到最後大家都很累，因為兩邊都能把容器跑起來，功能表看不出差別。

真正該問的是另一個問題：你的團隊願不願意接下 Kubernetes 這套 API 與它的治理責任。這篇就從這裡開始，一路談到版本升級、容器網路，以及一條可以被稽核的部署流水線。

容器治理真正的成本不在把服務跑起來那一天，而在之後每一次版本升級、每一次擴容、每一次半夜回滾。

選型不是比功能表，是問你要不要 Kubernetes

ECS 是 AWS 自己的容器編排服務，官方定位是完全託管的容器編排，讓團隊不必具備基礎設施管理專長也能跑起要求嚴苛的容器工作負載。

EKS 則是託管的 Kubernetes，官方定位是讓你在任何環境上輕鬆建置、執行與擴展正式環境等級的應用。關鍵字是任何環境。

所以分水嶺很清楚：你要的是「把容器跑起來」，還是「取得 Kubernetes 這套 API 與生態系」。這兩件事的代價不是用月費算的，是用團隊的長期注意力算的。

• 傾向 ECS：團隊沒有 Kubernetes 經驗、要學的概念愈少愈好、工作負載主要就在 AWS 上。
• 傾向 EKS：已經在用 Helm、Operator、服務網格這類生態系工具，或組織有跨雲與地端的可攜性要求。
• 兩邊並存：不同團隊各用一套很常見，只要治理規範是同一份就不算失控。

責任邊界：四層各自歸誰

與其記服務差異，不如記責任邊界。把一套容器平台拆成四層來看，你的維運工作量就一目了然。

這張圖是簡化示意。要注意的是，不論選哪一條路，VPC 基礎設施與叢集設定始終在你這一側，應用容器的可用性、安全與監控也是。

EKS 的治理面：版本、升級與那張新的安全網

託管 Kubernetes 最容易被低估的成本是版本節奏。Kubernetes 每年會出好幾個次要版本，EKS 跟著上線，而每個版本都有自己的支援期限。

以 2026 年為例，Kubernetes 1.35 於 1 月 28 日在 EKS 上線，1.36 於 6 月 2 日上線（依 AWS 官方公告，2026 年 8 月查閱）。這個節奏不會等你，實際的支援期限請直接查官方的版本生命週期頁。

2026 年 7 月 1 日 AWS 為 EKS 加上了一張新的安全網：Kubernetes 版本回滾。升級完成之後有一段時間可以回到前一個次要版本，官方公告的窗口是七天。

• 回滾之前會先跑自動就緒檢查，項目包含 API 相容性、版本對齊、附加元件相容性與叢集健康。
• 在 Auto Mode 叢集上，服務會先回滾工作節點，再還原控制平面。
• 官方公告說明這項能力在所有提供 EKS 的區域皆可使用，且不另外計費。

Auto Mode：AWS 把「剩下的」也收走了

EKS Auto Mode 的想法，是把 AWS 的管理範圍從叢集本身延伸到支撐工作負載的基礎設施。官方文件的說法是把運算自動擴縮、Pod 與服務網路、應用負載平衡、叢集 DNS、區塊儲存與 GPU 支援，都做成核心元件而不是附加元件。

實際落到維運上，最有感的是節點被當成家電來對待。以下幾點來自官方使用者指南（2026 年 8 月查閱）。

• 節點使用視為不可變的 AMI，採用 Bottlerocket 變體，鎖定軟體、啟用 SELinux 強制模式、根檔案系統唯讀。
• 不允許透過 SSH 或 SSM 直接登入節點，要加東西請改用 DaemonSet。
• 節點有最長生命週期，官方文件記載為 21 天，到期自動換新，你可以再縮短。
• 自動擴縮以 Karpenter 為基礎，偵測到無法排程的 Pod 就配新節點，工作結束就收掉。
• 升級會尊重你設定的 Pod 中斷預算與 NodePool 中斷預算。
• 要客製請新增自己的 NodePool 與 NodeClass，不要去改預設的那兩份。

容器網路：Pod 拿到的是真的 VPC 位址

這是 EKS 上最需要提早想清楚的一件事。Amazon VPC CNI 外掛會部署在叢集的每個 EC2 節點上，建立彈性網路介面掛到節點，再從 VPC 指派一個 IPv4 或 IPv6 私有位址給每一個 Pod。

換句話說，Pod 不是活在一層疊加網路裡，它就在你的 VPC 裡。這帶來的好處與代價一樣直接。

• 好處：安全群組、路由表、VPC 流量日誌這些既有工具直接適用，不必為容器另建一套網路可觀測性。
• 代價：子網的位址空間會被 Pod 吃掉，規劃不足的症狀不是報錯，而是叢集擴不出去。
• 提醒：官方文件說明，對於跑在 AWS 基礎設施上的節點，VPC CNI 是 EKS 唯一支援的 CNI 外掛；混合節點則要另外選擇 CNI 方案。

如果你走 Auto Mode，官方文件明確說你不需要自行安裝或升級網路附加元件，Pod 網路與負載平衡都已經包含在內。這是 Auto Mode 省下最多時間的地方之一。

ECS 這一側：Fargate、Express Mode 與內建藍綠部署

ECS 的兩種執行方式是 Fargate 與 EC2。Fargate 讓你完全不碰節點，EC2 則保留對執行個體的控制權，兩者可以在同一個叢集裡混用。

2025 年 7 月 AWS 為 ECS 加上內建的藍綠部署策略與部署生命週期掛鉤，這件事對流水線的影響很大。

• 新版本會與舊版本並存，讓你在導入正式流量之前先驗證。
• 支援從 ALB、NLB 或 ECS Service Connect 取得流量的服務。
• 失敗可以快速回滾，不必自己刻一套部署工具。
• 生命週期掛鉤讓你把自訂的驗證步驟插進部署過程裡。

另外，2025 年 11 月 21 日 AWS 推出了 ECS Express Mode，目標是讓開發者快速把網頁應用與 API 上線。它會幫你把網域與應用程式負載平衡器這類周邊架構備齊，同時你仍然保有對底層資源的完整控制權。

這條路很適合內部工具與原型。要注意的是，方便性來自預設值，正式上線前仍要回頭確認那些預設值符合你的安全與網路規範。

部署流水線：一條可以被稽核的路

工具選什麼沒那麼關鍵，關鍵是流水線有沒有這幾個性質。以下幾條跟你用 ECS 還是 EKS 無關。

1. 映像檔用摘要釘死。 用 latest 這種浮動標籤，等於讓「現在跑的是哪一版」變成猜謎，出事時第一步就卡住。
2. 建置一次，到處部署。 測試環境與正式環境要用同一個成品，只換設定，不重新建置。
3. 設定從外面注入。 環境差異放在參數與密鑰服務裡，不要編進映像檔。
4. 部署策略要明講。 滾動更新是預設值，需要先驗證再導流的服務就用藍綠，並在流水線裡留下驗證步驟的紀錄。
5. 回滾要演練過才算存在。 沒有人在平常演練過的回滾流程，在半夜就等於不存在。
6. 叢集狀態也要進版控。 不論是任務定義還是 Kubernetes 資源檔，都要能從版本庫重建，不能只活在主控台裡。