コンテナ基盤をAWSで組むとき、最初に突き当たるのがECSかEKSかという分岐です。この記事では両者の本質的な違いを、運用負荷・チームスキル・マルチクラウド要件・コストの4軸で整理し、Fargate起動との組合せも含めて現実的な選定の考え方をまとめます。
「とりあえずコンテナで」という要件は増えました。ですが実際に設計に入ると、最初の分岐で手が止まります。オーケストレーションを Amazon ECS で組むか、Amazon EKS（Kubernetes）で組むか。この選択はランタイムの好き嫌いではなく、その後数年の運用体制・調達・人員計画までを規定します。本記事では、両者の違いを実務の判断軸に落とし込んで整理します。
01そもそも何を選んでいるのか
AWSの公式な整理では、コンテナ関連サービスは「どこで動かすか（キャパシティ層）」「誰がスケジューリングするか（オーケストレーション層）」「上位の垂直統合サービス」の3層に分かれます（Choosing an AWS container service）。ECSとEKSはこのうちオーケストレーション層の選択であり、キャパシティ層である AWS Fargate / Amazon EC2 とは直交する軸です。
つまり「ECSかEKSか」と「Fargateかサーバー管理か」は別々の問いです。ここを混同すると議論がかみ合わなくなります。まずオーケストレーションを決め、その上で起動タイプ（キャパシティ）を決める、という順序で考えると整理しやすくなります。
02ECSの本質 — AWSネイティブの「軽さ」
ECSはAWSが自社で設計したオーケストレーターです。最大の特徴は、制御プレーン・ノード・アドオンを利用者が管理しなくてよい点です。IAM・VPC・ELB・CloudWatchといったAWSの各サービスと最初から地続きに設計されており、awsvpc ネットワークモードでタスクにENIが直接割り当たるなど、AWS上で運用する前提の割り切りが効いています。
公式の選定ガイドでも、ECSは「スケールや機能を犠牲にせず、ネットワークとセキュリティの構成をよりコントロールしたい場合の良い選択肢」と位置づけられています。学習コストが低く、少人数のチームでも本番運用に到達しやすいのが実務上の強みです。バージョンアップ計画や証明書更新、アドオンの互換性維持といった「Kubernetesを持つと発生する仕事」が構造的に存在しません。
03EKSの本質 — Kubernetes標準と移植性
EKSはKubernetesのマネージドサービスです。制御プレーンの可用性と運用はAWSが引き受けますが、その上で動くのはアップストリームに準拠したKubernetesのAPIです。ここが決定的な違いで、kubectl・Helm・各種Operator・CNCFエコシステムのツールがそのまま使えます。オートスケーリング、ネットワーク、メトリクス、ロギングといった領域でOSSのアドオンを選べる自由度が、EKSを選ぶ最大の理由です。
AWSの整理でも、Kubernetesを選ぶチームは「活発なエコシステムとコミュニティ、一貫したOSSのAPI、幅広い柔軟性」を求めており、その代わりにクラスターの構築と運用という「差別化に寄与しない重い作業」をEKSに肩代わりさせる、とされています。移植性も重要です。オンプレやマルチクラウドで同じKubernetesマニフェストを流用したい要件があるなら、この標準性は代えがたい価値になります。
一方でコストは「金額」だけではありません。公式の選定ガイドは、Kubernetesを運用する組織は強力なSRE体制に投資しており、Kubernetesが年に約3回のマイナーバージョン（1.x、およそ4か月周期）をリリースし、N-2ポリシーで直近3バージョンのみをサポートする（各バージョンの標準サポートは約14か月）ため、頻繁なクラスターアップグレードに対応している、と明記しています。この「アップグレードを回し続ける人と仕組み」を用意できるかが、EKS採用の実質的な前提条件です。
044つの判断軸で切り分ける
抽象論を避けて、選定を左右する4つの軸に落とし込みます。
- 運用負荷：ECSは制御プレーン・アドオン・バージョンアップの管理が構造的に不要。EKSはマネージドとはいえKubernetesの運用サイクル（アップグレード、CNIやアドオンの互換性維持）が発生します。
- チームスキル：Kubernetesの実務経験者とSRE体制があるか。無いままEKSを選ぶと、学習と運用の両方が同時に立ち上がり、初期のトラブルシュートで詰まりがちです。
- マルチクラウド／移植性：オンプレ・他クラウドで同じオーケストレーションを使う要件があるならEKS。AWS内で完結するならECSの割り切りが効きます。
- コスト：純粋なコンピュート費用はFargate/EC2の選び方でほぼ決まり、ECS/EKSの差ではありません。差が出るのは制御プレーン費用（EKSはクラスター単位で課金）と、人件費を含む運用コストです。数値・料金は改定されるため必ず公式料金ページで最新を確認してください。
05決定表 — 現実的な当てはめ
4軸を組み合わせると、典型的なケースは次のように整理できます。SIer/エンタープライズの現場で頻出するパターンに寄せています。
注意したいのは、この表を1行だけ見て決めないことです。たとえば「Kubernetes経験者がいる」からEKSに寄っても、その体制が2〜3年後も維持できるかは別問題です。人が抜けた後もアップグレードを回せるか、という時間軸で考えると答えが変わることは珍しくありません。
06Fargate起動との組合せ
オーケストレーションを決めたら、次は起動タイプです。AWS Fargate はサーバーレスのコンピュートエンジンで、EC2インスタンスの管理・キャパシティプランニング・OSパッチから解放されます。ECSでもEKSでもFargateを選べますが、両者で「できること」に差があるため、ここは要注意です。
ECS on Fargateは比較的素直です。awsvpc ネットワークモードが必須になる程度で、多くのWeb/APIワークロードは自然に載ります。加えてECSでは、公式が「起動タイプよりキャパシティプロバイダーの利用を推奨」しており、FARGATE / FARGATE_SPOT やAuto Scalingグループ、さらにFargateの手軽さとEC2の柔軟性を併せ持つ Amazon ECS Managed Instances をキャパシティプロバイダーとして選べます（launch types and capacity providers）。
EKS on Fargateは制約が多く、設計時に把握しておかないと後で詰みます。公式ドキュメントが明示している主な制約は次の通りです。
DaemonSetがサポートされない。ログやエージェント常駐をDaemonSet前提で設計しているとサイドカーへの作り替えが必要になります。- Podはプライベートサブネットでのみ動作する（NAT Gateway経由でのAWSサービスアクセスは可、IGWへの直接ルートは不可）。
Fargate Spotが使えない。コスト最適化でSpotを織り込む設計はEKS on Fargateでは成立しません。- Amazon EBSボリュームをマウントできない（EFSは可）。GPU・Arm・Windowsも非対応。
07SIer/エンタープライズの現実的判断
大手SIerやエンタープライズの案件では、技術的な最適解と組織的な最適解がずれることがよくあります。実務では次の観点を重ねて判断しています。
- 運用の引き継ぎ先：構築後に運用を担うのが誰か。情シスやグループ会社の運用チームにKubernetesの素養がないなら、ECSの方が引き継ぎが現実的です。
- 標準化ポリシー：全社でKubernetesに寄せる方針が既にあるなら、単一案件の都合でECSを選ぶと後で棚卸しの対象になります。逆に方針が未定なら、無理にKubernetesを持ち込む必要はありません。
- 統制との整合：マルチアカウント環境でのガードレールやIAM設計は、どちらでも必要です。ECSはIAMとの統合が素直な分、権限設計を型にしやすい面があります（マルチアカウント統制）。
- 移行しやすさ：ECSはキャパシティプロバイダー間の移行が公式にサポートされており、
UpdateServiceでFargateからEC2系へ寄せる、といった変更が後からでも効きます。まずECSで軽く始め、要件が育ってからEKSを検討する順序も十分に現実的です。
私たちが案件で最初に確認するのは、技術要件よりも「2〜3年後、誰がこれを運用しているか」です。ここが定まると、ECSかEKSかは自然と絞り込まれていきます。オーケストレーションが決まったら、CI/CDはAWSのコード系サービスによるCI/CD入門やIaC/CI/CDパイプラインで整えていきます。
—まとめ
ECSとEKSの選定は、ランタイムの優劣ではなく運用体制の設計です。要点を整理します。
- ECSとEKSはオーケストレーション層の選択で、Fargate/EC2という起動タイプとは直交する。まずオーケストレーションを決める。
- ECSはAWSネイティブで運用負荷が低く、少人数でも本番到達しやすい。EKSはKubernetes標準の移植性とエコシステムが強みだが、アップグレードを回すSRE体制が前提。
- 判断は運用負荷・チームスキル・マルチクラウド要件・コストの4軸で。単一軸で断定せず、2〜3年後の運用主体まで含めて総合判断する。
- Fargate組合せはECS側が素直。EKS on FargateはDaemonSet不可・Spot不可・EBS不可などの制約を設計前に把握する。
迷ったら、ECSで小さく始めて要件が育ってからEKSを検討する、という順序は多くの現場で無理がありません。数値・料金・上限はバージョン依存で改定されるため、最終判断の前に必ず公式ドキュメントで最新を確認してください。