ECS vs EKS — コンテナオーケストレーターの選択基準

インフラ AWS Kubernetes
読了 6分

コンテナの実行基盤(Fargate か EC2 か)を決めたら、残る選択はオーケストレーターです。ECS と EKS はどちらもコンテナのデプロイ・復旧・拡張をしてくれますが、片方は AWS 専用のサービスで、もう片方はマネージド Kubernetes という点で性格が異なります。結論を先に書くと、AWS の中でサービスを動かすことが目的なら ECS が基本で、Kubernetes エコシステム・可搬性・組織標準という明示的な要求があるときに EKS を選びます。 実行基盤の選択は ECS Fargate vs EC2 で扱ったので、この記事はその上の階層の選択です。

見た目の料金差 — コントロールプレーン月 $73 #

課金構造の違いは単純です。ECS のコントロールプレーンは無料で、タスクが使うコンピューティングだけを払います。EKS はクラスターあたり 1 時間 $0.10、月にして約 $73 です。本番・ステージング・開発でクラスターを分ければ 3 倍になります。

月 $73 自体は、大きな負荷のコンピューティング料金に比べれば少額です。落とし穴は別の場所にあります。EKS の Kubernetes バージョンは標準サポートが 14 か月で、その間にアップグレードしないと延長サポートに移り、クラスター料金が 1 時間 $0.60、月約 $438 と 6 倍になります。Kubernetes は年に 3 回ほど新バージョンが出るので、EKS を使うということは、年 1〜2 回のクラスター・アドオン・ワークロードの互換性検証作業を常設の予定に入れるという意味です。このアップグレードの労働が EKS の実際の固定費です。

運用モデルの違い — AWS が何をして、何が残るか #

ECS はスケジューラ、API、統合がすべて AWS サービスの中で閉じています。タスク定義を書いてサービスとしてデプロイすれば、ALB の接続、IAM 権限(タスクロール)、CloudWatch のログ・メトリクスが追加の部品なしで付いてきます。バージョンアップグレードという概念自体がなく、学ぶことはタスク定義とサービスの概念くらいです。対価は選択肢の狭さです。スケジューリングポリシー、デプロイ戦略、ネットワークモデルのすべてが AWS の決めた方式の中で動きます。

EKS は標準の Kubernetes API を提供し、その上は Kubernetes の世界のルールに従います。Helm チャートでデプロイし、Ingress コントローラーを選び、HPA・オペレーター・CRD を使います。AWS が管理してくれるのはコントロールプレーン(etcd、API サーバー)までで、アドオン(CNI、CoreDNS、メトリクス、Ingress)とノード運用、バージョン互換性は利用者の持ち分です。2024 年末に出た Auto Mode は、ノードのプロビジョニング・パッチ適用・統合(ロードバランシング、ストレージ)を AWS が代行する構成で、この持ち分をかなり減らしてくれます。対価は管理対象ノードのインスタンス料金に 10% 前後が乗る追加料金です。Auto Mode を使っても、ワークロード側の Kubernetes の知識(マニフェスト、RBAC、アップグレード検証)はそのまま必要です。

EKS が正解になる条件 #

  • Kubernetes エコシステムが本当に必要な場合: 特定のオペレーター(データベース、メッセージング、ML パイプライン)、サービスメッシュ、Argo CD のような GitOps ツール、組織がすでに持っている Helm チャートの資産が該当します。基準は「使える」ではなく「これなしでは成り立たない」です。
  • 可搬性・マルチクラウドの要求: オンプレミスや他クラウドと同じマニフェストで運用する必要がある組織、あるいは特定クラウドへの依存を契約上避ける必要がある場合です。
  • 組織標準が Kubernetes の場合: すでに k8s を運用するチームがあり、採用・教育・ツールがそちらに揃っているなら、ECS を別に学ぶほうがむしろコストです。

これらの条件に該当しない小規模チームが EKS を選ぶと、サービス開発よりクラスター運用(アップグレード、アドオンのバージョン合わせ、ネットワークの問題)に時間が流れていきます。逆に条件に該当するのに ECS を選ぶと、エコシステムのツールを一つずつ自前で実装することになります。

乗り換えは思ったより大きい作業です #

ECS と EKS はデプロイの単位(タスク定義 vs マニフェスト)、権限モデル(タスクロール vs IRSA・Pod Identity)、ネットワークモデルがすべて違うので、移行は書き直しに近い作業です。だから「まず ECS で始めて、大きくなったら EKS へ」という計画は成立しますが、安くはありません。組織が 2〜3 年以内に Kubernetes 標準に行くことが確実なら最初から EKS で始めるほうが移行コストを節約でき、その確信がなければ ECS で始めて必要が証明されたときに移るのが正しい順序です。EKS を選ぶなら、クラスター構築・IRSA・アドオンの実務は K8s 実践 #1 で、Kubernetes 自体の入門は K8s 基礎 で扱いました。

選択の手順 #

  1. エコシステムの要求を検証します: 必要なのがコンテナの実行・拡張・復旧だけなら ECS で足ります。オペレーター・GitOps・メッシュの中に「ないと成り立たないもの」があれば EKS です。
  2. 運用の担当者を数えます: クラスターアップグレードを年 1〜2 回実施する担当がいなければ、EKS は延長サポート料金(6 倍)で漏れていく道です。それでも EKS が必要なら、Auto Mode でノード運用の持ち分を減らします。
  3. 実行基盤と組み合わせます: ECS でも EKS でも、Fargate と EC2 ベースを選ぶ軸は 同じ基準 がそのまま適用されます。EKS の Fargate は DaemonSet 不可などの制約があり、主に補助的な用途です。
  4. クラスター数を計画します: EKS はクラスターごとの課金なので、環境を分けた数だけ固定費が増えます。小規模なら、クラスターを分ける代わりに Namespace で分離するのも選択肢です。

まとめ #

  • 課金の差はコントロールプレーン(ECS 無料、EKS 月約 $73)ですが、実際の固定費は EKS のバージョンアップグレードの労働です。放置すると延長サポートでクラスター料金が 6 倍になります。
  • ECS は AWS 統合が完結した閉じたサービス、EKS は標準の Kubernetes API を提供する開かれたプラットフォームです。自由度と運用負担は一緒に動きます。
  • EKS の根拠は三つです。ないと成り立たない k8s エコシステムのツール、可搬性・マルチクラウドの要求、Kubernetes に揃った組織標準です。
  • Auto Mode はノード運用を AWS に渡す代わりに、インスタンス料金に約 10% を乗せます。ワークロード側の k8s の知識はそのまま必要です。
  • 両者の間の移行は書き直しに近い作業です。数年内の k8s 標準化が確実なら最初から EKS、そうでなければ ECS で始めて必要が証明されたときに移ります。
X