ECS on Fargate vs EKS on EC2

こんにちは。SREグループの蜂須賀です。
弊社ではEKS on EC2 and Fargateを中心にシステムを構築していますが、最近は一部のシステムをECS on Fargateでもシステム構築しています。
そこで今回はECS on FargateとEKS on EC2の比較をさせていただきます。
なお、2025年8月14日時点のものになります。

ECS on Fargateのメリット

学習コストが低い

ECSとEKSの学習コストを比較したときに、ECSの方が学習コストは低いです。
ECSはWebコンソール内で完結できるので、設定する項目数が少ないです。
EKSはKubernetesマニフェストの設定が多く、学習する範囲と項目は多くなります。
基盤専門チームが設定する場合やサポートを手厚くできる場合はそれほど気にしなくても良いと考えます。
バックエンドの開発チームでKubernetesマニフェストも管理していく場合には、学習コストが高いと考えます。

運用コストが低い

ECS on Fargateの場合、基盤側のバージョンアップ作業による運用コストが少ないです。
プラットフォームバージョンに関しては管理する必要がありますが、最新の1.4.0が2020年4月にリリースして以降、新しいバージョンはリリースされていません。

クラスター費用が発生しない

ECS on Fargateでは動いているコンテナにのみ料金が発生しますが、EKSではクラスターにも料金が発生します。
EKSはリリース後最初の14ヶ月間が標準サポートとなり、次の12ヶ月間は拡張サポートとなります。
標準サポートの期間であればクラスターごとに0.1ドル/hですが、拡張サポート期間に入るとクラスターごとに0.6ドル/hの費用がかかります。
1ドル145円と仮定した場合、クラスターごとに標準サポートは約10,500円/月、拡張サポートは約63,000円/月になります。

EKS on EC2のメリット

ワーカーノードのインスタンスタイプを選択できる

EKS on EC2ではワーカーノードのインスタンスタイプを選択できます。
ECS on FargateではCPUとメモリーのサイズとオペレーティングシステム/アーキテクチャしか選ぶことができません。
GPUや、バーストパフォーマンス(T系)インスタンス等の特定のインスタンスタイプを使いたい場合はECS on Fargateでは現状実現できません。
以下はオペレーティングシステム/アーキテクチャをLinux/X86_64にして、タスクサイズを2パターン設定し、それぞれ10回ずつ起動した時のCPUの調査結果です。

1vCPU/2GB

Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz: 9台（m5で使用されるCPU）
Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz: 1台（c5で使用されるCPU）

2vCPU/4GB

AMD EPYC 9R14: 6台（c7aで使用）
Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz: 2台（m5で使用されるCPU）
Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz: 2台（m5で使用されるCPU）

上記の結果から、EC2インスタンスの仕様に合わせてFargateの料金を比較しました。

料金比較(ap-northeast-1)

インスタンスタイプ	vCPU/メモリ	料金（$/h）
c7a.large (EC2)	2/4GB	0.1292
c7i.large (EC2)	2/4GB	0.11235
c5.large (EC2)	2/4GB	0.107
Fargate(2vCPU/4GB)	2/4GB	0.12324
m5.large (EC2)	2/8GB	0.124
Fargate(2vCPU/8GB)	2/8GB	0.14536

Linux/X86_64を指定した場合は、Intel製CPUだけでなく、AMD製CPUでも起動することは注意が必要です。
ECS on FargateはEC2と比較して料金が高いという先入観がありましたが、AMD EPYC 9R14のCPUの場合にはEC2よりもFargateの方が安くなるという結果は驚きでした。
しかしながら、AMDで起動することにこだわりがなければ、c7i.largeで起動した方がc7a.largeやFargate(2vCPU/4GB) よりも料金は安くなります。

c5、m5で使用されているCPUで起動する場合はEC2料金と比較して約15-20%割高になります。
また、c6i、m6iはc5、m5と料金は同じですが、CPUの処理性能が向上しているため、処理能力を考慮するとコストパフォーマンスの差はさらに大きくなります。
インスタンスタイプが選択可能なことで、ノードの料金を抑えることができます。

Podのサイズを柔軟に設定できる

ECS on Fargateの場合は、1タスクごとにCPUとメモリーを割り当てることになり、割り当てられるサイズは決まっています。
メトリクスを見て、タスクサイズを必要最小限に設定しても、割り当てられるサイズが決まっているため、使われていないCPUやメモリーが発生しやすいと考えられます。

EKS on EC2の場合は、ワーカーノードに複数のPodを配置できるのでサイズを柔軟に設定できます。
ワーカーノード内のリソースをなるべく余らないように調整することでノード効率を高められます。
逆にサイズの調整を考慮していないと、必要以上にワーカーノードが起動してしまうので注意も必要です。
Podの負荷がない時やスケーリングする時で、Pod数や配置がその都度変わってしまうので、色々なパターンを想定しながら調整することが必要になります。
弊社でも定期的にサイズの見直すことで、EC2料金の削減につなげています。

Spotインスタンスが使いやすい

EKS on EC2ではSpotインスタンスが利用しやすいです。
Spotインスタンスのインスタンスタイプとサイズを複数選ぶことでSpotインスタンスの枯渇対策ができます。
また、Spotインスタンスが枯渇して起動できない場合でも、代わりにオンデマンドインスタンスを起動するように設定もできます。
ECSでは枯渇した場合にSpotキャパシティーをオンデマンドキャパシティに置き換えできないので注意が必要です。

なお、ECS on FargateにはSpotキャパシティーはありますが、EKS on FargateにはSpotキャパシティーはありませんのでご注意ください。

DaemonSetが利用できる

ECS on Fargateであれば、ログやメトリクスを収集する場合等にSidecar方式でタスクにコンテナを追加することになります。
EKS on EC2であれば、DaemonSetでワーカーノードごとにコンテナを追加することで賄えるケースが多くあります。
タスクごとでなくワーカーノードごとになる分、コンテナ数を減らすことができるので総体的なリソース量は削減できます。

柔軟に終了処理が設定できる

ECSではタスクの終了時にELBから登録解除処理をして、SIGTERMを送り、stopTimeout(最大120s)の間待機して、SIGKILLを送ることになります。
EKSでは、SIGTERMを送る前にpreStopコマンドを実行できます。
また、terminationGracePeriodSecondsで終了処理の最大待機時間を設定できます。
弊社ではこの機能を利用し、Sidekiqで長い処理の実行中でも処理を完了してから終了するようにしています。

SIGTERMに関しても、DockerfileのSTOPSIGNALで送るシグナルを変更できます。
Kubernetes1.33からはFeatureGateですが、Kubernetesマニフェスト側からシグナルを変更できるようになっています。

EKS on EC2のデメリット

運用コストが高い

EKSでは以下のようなバージョンアップを定期的に実施していく必要があるので、ECSに比べて運用コストが高くなります。

EKSクラスターのKubernetesバージョン
EKSのワーカーノードのAMI
クラスター内のコンポーネントの管理（aws-node、kube-proxy等）

EKSクラスターのKubernetesバージョン

EKSはリリース後最初の14ヶ月間が標準サポートとなり、次の12ヶ月間は拡張サポートとなります。
以前までは特定のメジャーバージョンを使用できるのは最大でも14ヶ月でしたが、現在では26ヶ月使用できるようになっています。
ただし、拡張サポート期間のクラスター料金は通常時の6倍かかるため、基本的には拡張サポートが始まる前にバージョンアップ作業をするのが良いと考えます。
弊社では標準サポート期間内にバージョンアップ作業することを目指していますが、他のタスクの兼ね合いやEKSで利用しているツールのバージョンアップ待ち等で、どうしても遅れが発生する場合は拡張サポート期間に入ることも許容して運用しております。

クラスター内のコンポーネントの管理

EKS on EC2では、aws-node、kube-proxy等の基本的なコンポーネントも管理する必要があります。
また、aws-load-balancer-controllerやcert-manager等の運用上必要になるコンポーネントも管理する必要があります。
バージョンアップ等の運用コストもありますが、これらのコンポーネントもワーカーノードのリソースを利用することは忘れてはいけないポイントです。
リソースをそれほど使うわけでないですが、インスタンスサイズが小さい場合には相対的に比重が大きくなるので、小規模なシステムの場合にはECSの方が良いと考えます。

また、弊社ではこれらの運用コストを減らすために、EKSアドオンを積極的に利用しています。
EKSアドオンには最新のセキュリティパッチ、バグ修正が含まれており、EKSと連携するためにAWSにより検証されています。
安全性と安定性を一貫して保証でき、アドオンのインストール、設定、および更新に必要となる作業量を削減できます。
最近ではCommunityアドオンという種類のアドオンもリリースされ、アドオンの数も増えています。
ただし、MarketplaceアドオンのEKSの新バージョンへの対応が2ヶ月近く後だったりと使いづらさを感じる場面もあります。