こんにちは。技術本部 技術戦略推進部の髙橋 洋樹です。AWSのコンテナ入門編として、Amazon ECS（以下、ECS）とAmazon EKS（以下、EKS）の違いをご紹介している本ブログシリーズ。前回は、ECSとEKSの概要についてご説明しました。まだお読みでない方は、ぜひ「AWSコンテナ入門（1）：Amazon ECSとAmazon EKSの役割と概要」からご覧ください。
今回はECSとEKSを適切に使い分けるために覚えておきたい「選択の観点」を以下の通りご紹介していきます。本ブログはあくまで個人的な見解ですが、理解の一助となれば幸いです。
前回の「AWSコンテナ入門（1）：Amazon ECSとAmazon EKSの役割と概要」でご紹介したECSとEKSの違いも踏まえつつ、コンテナを管理する際に、ご自身が優先する観点は何か、改めて考えてみてください。
各サービスの違い
横にスクロールできます
ECSとEKSでは適用するシステム規模によって学習コストが異なってくると考えています。小規模な環境ではECSの学習コストが低い傾向があります。なぜなら前回のブログでも紹介した通り、ECSの方がサービスとしての概念（リソース）がシンプルであり、AWSのコンソール経由で直感的に操作ができるため、タスク作成や他サービスとの連携も容易に実践することができます。その結果、ECSは初学者でも比較的早く基本操作を習得できるのです。一方、EKSは Kubernetes（以下、K8s）のもつ多数の概念を理解した上で、実現したい構成をコード（マニフェスト）に落とし込む必要があるため、より学習コストがかかる傾向があります。
ここまでは当たり前のように聞こえるかもしれませんが、ポイントは、システム規模が大きくなった場合、ECSとEKSの学習コストの差が縮まってくるという点です。規模が大きくなるとECSと連携してくるAWSサービスの数や種類が多くなり、各サービス詳細の理解も必要になってきます。特にAWSのコンソールをメインに運用している場合は、状態を把握するために各サービスの画面を行き来するのが煩雑になってきます（Terraform等で運用している場合この限りではありません）。そのため、システム規模がある程度大きく、どちらかのサービスに長けた既存のメンバがいない場合、AWSとK8sのどちらに対して学習コストを「より」払っていきたいかという観点で考えるとよいと思います。
システム規模に関わらずEKSの方が総じてランニングコストは高くなる傾向があります。理由は①サービス課金体系と②バージョンアップコストがあげられます。
EKSはクラスタを動かしているだけで1時間当たり0.1USD、月額に換算すると約75USDの時間課金が発生します（2024/5現在のオハイオリージョンの価格）。一方で、 ECSはクラスタの稼働に課金が発生しません。そのため、小規模な利用、たとえばある特定のタイミングだけコンテナのワークロードを動かす必要がある、もしくは、常時ワークロードを動かす必要はあるが必要とするノードの数やスペックが高くない場合は相対的にECSのほうがコスト面は有利です。
EKSではクラスタのバージョンアップにかかるエンジニアリングコストが発生します（ECSではクラスタのバージョンアップは発生しません）。EKSのベースとなっているK8sはおよそ4か月に一度、新しいマイナーバージョンがリリースされます。そのため、少なくとも四半期に一度はバージョンアップ対応に工数を割かなければなりません。加えて、マイナーバージョンのサポート期限は14ヵ月となっており、この期間を過ぎると強制的にバージョンが上がってしまうため、塩漬けするという選択肢は取れないことになります。
バージョンアップには、サービス影響を及ぼす可能性がある内容も当然含まれます。例えば、K8sを構成するリソースのAPIに破壊的な変更が加わった場合などです。その場合、バージョンアップ前まで成功していたリソースの作成が失敗し、最悪サービス停止が発生する恐れがあります。従って、事前にバージョンアップの検証コストを見込んでおく必要があるのですが、大規模システムになると使用するK8sリソースの種類も数も、サービス連携先も必然的に増加するため、現場にとっては大きな負荷となります。
クラスタのバージョンアップは不可逆です。そのため、バージョンアップ運用を考える上では既存のクラスタをインプレースでアップグレードするのか、新バージョンが公開されるたびに新しいクラスタを構築し、動作確認が全て済んだら古いクラスタからトラフィックを切り替えるのか、リスクとコストを天秤にかけた運用設計が必要になります。
EKSの方が移植性に優れます。EKSがベースとするK8sはオンプレミスで動かすことができることに加えて、Microsoft AzureやGoogle Cloudからマネージドサービスが提供されています。そのため、例えばオンプレミスですでにK8sを運用しており、コンテナの基盤をAWSにも拡張したいというような場合はEKSが第一の選択肢となるでしょう。
一方でECSはAWSが独自開発したコンテナオーケストレーターでコードも公開されていません。AWSが提供するAmazon ECS AnywhereやAWS Outpostを使用することで、ECSによって管理されたコンテナ（データプレーン）をAWS外で動かすことは可能です。ただし、ECSのコントロールプレーン自体は引き続きAWSの中に存在するため、ECSを利用する場合、いずれの場合もAWSへの依存をなくすことができません。
ECSもEKSもコンテナの継続的デリバリを実現できます。Amazon ECSはAWS CodeDeployとのインテグレーションが可能で、カナリアリリースを伴うBlue/Greenデプロイのような複雑なデリバリを容易に実現できます。CodeDeployは、AWSがマネージドで提供するデプロイサービスです。アプリケーションの新旧バージョンを同時にデプロイし、トラフィックを徐々に新バージョンにシフトさせる柔軟なデプロイが可能です。一方、Amazon EKSではGitOpsと呼ばれる手法を採用することが一般的です。GitOpsとは、Gitリポジトリ上のマニフェストファイル(K8sリソースの宣言的な定義)の内容と、実際のクラスタ上のリソース構成を同期させる仕組みです。ArgoCD、FluxなどのGitOpsエンジンを使うことで、Gitリポジトリ上の変更を自動的にクラスタに反映させることができます。
AWSのマネージドなコンテナオーケストレーターであるAmazon ECSとAmazon EKSについて選択の観点を4つ述べました。改めて差異を整理すると、下表のようになります。
また、これまでの比較から、各サービスの利用を推奨するシチュエーションをまとめると以下のようになります。
Amazon ECSを推奨するシチュエーション
Amazon EKSを推奨するシチュエーション
どちらを採択するのがベターなのかは案件個別の事情によって毎回異なるため、状況に応じて適切な選択をしていきたいところです。選択に迷われた際には、ぜひ、当社で提供するAWS包括的技術支援サービスをご活用ください。また、そもそも拡張性の高いシステムを構築していくために、コンテナ含めて様々な技術をどのように組み合わせていけばいいのか？というお悩みをお持ちの方には、ITシステム構築の上流工程ノウハウ提供からSI実務の細かなご相談に至るまで、お客様とともに考えご支援する、伴走型のプロフェッショナルサービス「xSource（クロスソース）」もご提供しておりますので、あわせて詳細をご覧ください！
