ECSがAWS独自の技術であるのに対し、EKSは基本的にAWSが開発・保守するKubernetes-as-a-platformのサービスです。EKSクラスターは実はポータブルで、バニラK8を使ってローカル環境、開発環境で同様の体験を再現できます。したがって、どのシナリオでクラウドベンダーロックインのリスクに直面するかがわかります。

ECSでアプリケーションを構築・運用していると、長期的にはベンダーロックインの問題に遭遇する可能性があります。ほかのプロバイダーを使うことになれば、プロバイダーに合わせてアーキテクチャー全体を定義しなければならなくなります。

そのため、EKSで動作するようにアプリケーションを設計することで、より柔軟性を確保できます。EKSの抽象化レイヤーは、コンテナーをパッケージ化して別のプラットフォームに素早く移動させるのに役立ちます。オンプレミスや、よりよい取引を提供してくれるクラウドプロバイダーなどの、ほかのKubernetesクラスターでワークロードを実行できるようになります。

そのうえ、さまざまなマネージドKubernetesサービスをシームレスに切り替えることができるソリューションが市場に出回っています。

ソリューションに関連する重要なポイントとして、オープンソースとコミュニティーがあります。

EKSでは、多くのツールが構築されており、コミュニティー自体も急速に成長しています。多くの問題が既に解決されているため、多くのサポートを受けることができます。

オープンソースの場合はツールを選ぶことができますが、ECSの場合はすべてが独自で、最終的な自由度はあまり残されていません。

Amazon ECSでは、awsvpcという1つのネットワークモードだけを使用して、タスクにエラスティック・ネットワーク・インターフェース（ENI）を割り当てることができます。通常、EC2インスタンスあたり8から15個のネットワークインターフェースしか取得できませんが、ECSでは（特定の前提条件を満たす場合は）それ以上の制限を持つコンテナーもサポートします。合計で、EC2インスタンスあたり最大120タスクまでであれば、実行できます。

EKSでは、ネットワークの柔軟性が大きく向上します。複数のポッド間でENIを共有し、インスタンスごとにより多くのポッドを配置できます。

名前空間は、同じKubernetesクラスター内で動作するワークロードを分離するために便利です。1つのクラスターに開発環境、ステージング環境、本番環境を置くことができます。これらはすべて、クラスターのリソースの共有ができます。

困ったことに、ECSでは名前空間は使うことができません。このソリューションには、概念として含まれていないのです。対してEKSでは、セルフマネージドKubernetesと同じように名前空間を使うことができます。

多くの人がECSを選ぶのは、とても簡単だからです。しかし、その代償として、設定オプションが制限されます。クラスターノードにアクセスできないので、トラブルシューティングの能力が制限されます。

また、ECSをFargateと一緒に使う場合は、さらに、多くの制限を覚悟しておく必要があります。EKSのように、環境固有の設定をコンテナーイメージから簡単に切り離し、移植性を高めるというオプションはありません。

最初に、ECSタスク定義ファイルをKubernetes deployment YAMLに書き換える必要があります。この部分は避けることができず、ECSとEKS（またはバニラKubernetes）で最大の違いの1つに関連するものです。

また、EKSにあるそれぞれの環境のバージョンをスピンアップする必要があります。通常、Terraform、CloudFormation、またはPulumiによる、Infrastructure as Code（IaC）を使用します。よいニュースです。これらの最も人気があるIaCツールは、EKSをサポートしています。

既にDockerに慣れており、アプリケーションイメージをパッケージ化して利用できる状態であれば、

• Terraform（または代替のIaCツール）のKubernetesプロバイダーを使用して、deployment YAMLをIaCフローの一部としてディプロイできます。
• アプリケーションパッケージがHelmを使用している場合は、Helmプロバイダーを利用できます。
• または、アプリケーションがHelmを使用してパッケージ化されている場合、ワークロードをEKSクラスターにディプロイできるCloudFormationを使用できます。

このほかにもさまざまな方法で上記を実現でき、それぞれに長所と短所があります。しかし、始めはこの簡単な方法で充分です。

アプリケーションをEKSクラスターにディプロイするために、必要な作業となります。

ECSとEKSはどちらも同様のネットワーク機能をサポートしています。ALBとNLBです。現在ECSで慣れ親しんでいるネットワークの基本的な構成を使用できます。ALBを使用したingressの詳細を知りたい場合、この記事が役に立つと考えることができます。

新しい構成に対してテストスイートを実行して、すべてが適切に機能することを確認します。

トラフィックの切り替えは構成により異なることがありますが、何する必要があるかを理解するための記載となります。

• ドメインが指すIPを切り替えて、EKSクラスターが使用するロードバランサーを指すようにできます。このようにして、アプリケーションのトラフィックがEKSクラスターを指していることを確認できます。
• ステートフルなアプリケーションの場合、K8sベースのアプリケーションがデータベースのメインユーザーとして移行するようにするなど、いくつかのことを考える必要があります（ECSが書き込みにデータベースを使用している状態から、EKSアプリケーションが書き込みにデータベースを使用する状態にスムーズに切り替わるかなど）。