為什麼 Amazon EKS 不是 Kubernetes 的預設答案
Amazon EKS 很強，但它不該成為每個 Kubernetes 團隊的預設選擇，因為便利會換來 AWS 綁定與更高的長期轉換成本。
Amazon EKS 很強，但它不該成為每個 Kubernetes 團隊的預設選擇，因為便利會換來 AWS 綁定與更高的長期轉換成本。
Amazon EKS 讓 Kubernetes 更好管，但它也把團隊推進 AWS 的決策框架裡，久了很難抽身。
第一個論點
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
EKS 的確省事。AWS 代管控制平面，還把身分、網路、安全與監控一起接上去；連 EKS Auto Mode 都進一步把運算、儲存、網路包進去。對缺平台團隊的公司來說，這不是小優勢，而是直接少掉一整層維運成本。
但便利不是中立。AWS 2024 年 AWS 收入約 1,080 億美元，靠的正是把更多工作留在自家生態裡。當你的叢集預設使用 IAM、ALB、EBS、CloudWatch，Kubernetes 就不再只是 Kubernetes，而是 AWS 風格的 Kubernetes。你省下的是今天的人力，換來的是明天的架構慣性。
第二個論點
AWS 很會賣「可攜性」這個故事。EKS Hybrid Nodes、Outposts、EKS Anywhere 都在傳達同一件事：你可以在雲、機房、邊緣用同一套操作模型。這對做混合部署的團隊很有吸引力，尤其是需要快速交付又不想重造平台的人。
但「操作一致」不等於「工作負載可移植」。一旦你把核心服務綁到 AWS Load Balancer Controller、IRSA、EBS CSI Driver，應用的可搬移性就開始下降。CNCF 2023 年調查顯示，Kubernetes 使用者中有超過八成同時在多雲或混合環境運作，這代表大家想要的是選擇權，不是把選擇權交給單一供應商的預設路徑。EKS 會讓你看起來很標準，實際上卻越來越 AWS 專屬。
反方可能怎麼說
最強的反方論點很清楚：大多數團隊根本不想自己維護 Kubernetes。他們要的是穩定、合規、可擴充，還有能支撐資料、AI、微服務的雲端底座。對這些團隊來說，EKS 不是鎖定，而是把不該自己做的事交給 AWS。
這個說法成立，而且對很多公司來說足夠成立。若你的主要限制是維運能力，而不是雲中立性，EKS 當然合理。問題在於，很多團隊把「合理」誤當成「預設」。
我的反駁是：如果 AWS 本來就是你的重心，就直接承認，並圍繞它設計；如果你的產品需要未來有退出、搬移、議價的空間，就不要把 EKS 當成無代價的預設。它不是泛用 Kubernetes 抽象層，而是 AWS 先行、Kubernetes 其次的平台。
你能做什麼
如果你是工程師或平台負責人，只有在 AWS 原生整合真的是產品策略的一部分時，才把 EKS 放進預設方案；同時建立薄薄的可攜層，盡量避免把 IAM、LB、儲存與觀測直接寫死在業務邏輯裡。若你是創辦人或 PM，把 EKS 視為「加速進 AWS」的工具，而不是「通用 Kubernetes」的答案，因為前者能幫你快，後者只會讓你誤判未來成本。