0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

EKSとECSの棲み分けが最近見えてきた話 〜AWS Summit Japan 2026 現地レポート〜

0
Posted at

AWS Summit Japan 2026 に現地参戦してました。
今回も割りかしAI要素多めながら、懲りずにコンテナ周りを探索しておりまして、いろいろ良い経験とか出会いもありましたのでそのポエムです。

EKS vs ECS! な時代はもう過ぎてる

同じコンテナ系サービスとして、ECSとEKSのどっちがいいの問題はよく語られてきたかと思います。数年前までは、自分はどちらかというとECS推しの立場でした。Kubernetesにも触れた上でですが、その学習コストや運用コストの高さがネックだな〜と感じており、「AWSでコンテナやるならECSっしょ!」みたいなノリでした。

今回のSummitで気になるセッションがあったので参加して来ました。チョークトークとのことだったので、折角なら積極的に質問していこうと最前線に張り付いていたのですが、気づけば結構喋ってしまっていました。
↓↓セッション資料はこちら

このセッションでも触れられていましたが、EKSの良い点は下記になるかと思います。

  • Kubernetesというプラットフォームを共通基盤とすることによる各CSPとの協調性
  • 機能性や各種サービスプラグインとの親和性

これらを兼ね備えている部分が大きな強みかと思います。
その上で、エンジンバージョンの更新という運用負荷はありますが、このエコシステムの恩恵を受けられるという点が特徴です。また、EKS Capabilitiesのような補完機能も充実しており、よりEKSエコシステムの様相が見てとれます。

ECSはというと、

  • AWSネイティブなコンテナオーケストレーションツール
  • 各種AWSサービスとの親和性の高さ
  • Kubernetesのエンジンバージョン更新といった保守作業が無いため、導入ハードルが低い

こういった点が強みです。ただし、ECSサービスとしての概念を理解する必要はもちろんありますし、より多様なモジュールをマイクロサービスとして構成する場合、ECS単独で全てを賄うというよりはAWSサービスを組み合わせていく中で最適化するという設計思想になりがちで、EKSのようにKubernetesの世界で全てを完結させるような多機能性は、ECS単体で見ると見劣りしがちです。

ここまでを見ると、

  • ECS→導入ハードルが低く小規模なプロダクト
  • EKS→Kubernetesの特性の恩恵を受けつつより効率的に大規模なマイクロサービス群

といった、規模感の違いによる棲み分けが見えてきます。
もはやEKSとECSは優劣を競う関係ではなく、それぞれの得意領域がはっきりと分かれてきているというのが、今回改めて感じたことです。

コンテナ×AIの文脈

AIが台頭していく中で、コンテナ技術はどちらかというと推論実行を行うサンドボックス環境としての用途で意識されることが多くなって来ているのかなと感じています。
例えば下記の記事で触れられているような構成を想定しています。

その流れでいくと、ECSは引き続き、AWSでサクッと推論コンテナを動かすための基盤という位置付けになってくるのかなと考えています。ただ、AgentCoreのようにそういった実行環境自体への意識も薄れていく方向性もあるため、その点ではあまり注目されないのかもな〜とも感じました。とはいえ、コンテナ技術自体が廃れることはないだろうという考えもあるので、ECS自体は今後も何かしらのアプリケーションプラットフォームとしての用途は残り続けるかなと考えています。

推論プラットフォームとしては、EKSもまた選定対象になるかなと思います。
ただ、EKSに関しては他の用途での活用パターンもありそうでして、そちらについても今回のAWS Summit で見てきた興味深いブースコンテンツがありましたので、次章で紹介します。

プラットフォームエンジニアリング×EKS

こちらについては去年も同様の展示を見ていて興味はあったのですが、今年も見てきました。今年はよりAI色が強くなったなという印象でした。

リファレンスのベースは恐らく下記ですが、Summitのブースにおいてはもう少しAI要素も絡んだ話がありました。

構成としては、EKS Capabilitiesを駆使してDeveloperへの環境提供機能(kro + Argo CD)とACKを用いたAWSリソース管理を行い、マニフェストリポジトリに対してAIコーディングエージェントでSkillも駆使しながら開発と運用を自動化する、というのがざっくりとした内容でした。

関連するSkillsは下記で公開されているようです。個人的にはプラットフォームエンジニアリングといった一見複雑そうな構成においても、知見やベスプラをSkillとして凝縮してそれを駆使すれば割と簡単そうに同じ構成を作れてしまうという点で、改めて生成AIの威力を痛感した次第です。

EKSでアプリの構成管理はもちろん、AWSリソースも管理してしまうという、まさにEKSエコシステムを象徴するような構成でした。Kubernetesさえわかれば全てをEKSでやれてしまうという思想です。ここから見ても、もはやECSとは思想も大きく異なるサービスとなってきている感触が強いです。また、プラットフォームエンジニアリング基盤というこれまた規模が大きい構成を、なるべく低負荷で実現できてしまうというところが、今のEKSの大きな強みなのかなと思います。

まとめ

初期のEKSが登場しだした頃、同じコンテナサービスとしてECSとの比較をよくしていたなと感じつつ、当時はKubernetesの学習コストや運用コストの高さを忌避してECS推しだったなと思っていました。現在はサービスとして大きく装いが異なってきており、それぞれに適切な棲み分けが当時よりもはっきりし出しているなというのを感じていたため、今回のポエムを書いてみました。

あとは生成AIやっぱすごいというか、Skillsの使い所とかについては割と真面目に感銘を受けたところがあるので、自分も使ってみようと思うのは勿論、こういう形で形式知を残していけるようにならんといかんなぁと思ったところです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?