#regrowth 2025 大阪で EKSのアップデートを2つ紹介しました

#regrowth 2025 大阪で EKSのアップデートを2つ紹介しました

2025.12.15

2025/12/10 に開催された AWS re:Invent 2025 ふりかえり勉強会 re:Growth 2025 大阪 にて登壇いたしました。お越しくださった皆様、ありがとうございました!

私はEKSのアップデートを2つご紹介しました。本エントリはその内容をブログ向けに改変したものになります。


まずは1つ目の機能のご紹介です。

Container Network Observability for EKS

Container Network Observability for EKS.png

課題: マイクロサービスの成長 → ネットワーク監視の複雑化

Kubernetesクラスターを運用するにあたっての課題の一つに、「マイクロサービスが成長することでネットワーク監視が複雑になってくる」というものがあります。

まずはマイクロサービスの復習です。アプリケーションを小さな独立したサービスに分割するアーキテクチャを指します。対義語はモノリスアーキテクチャなどと言われます。

このアーキテクチャを採用することによって、サービスごとに

  • スケールができる
  • 改良(デプロイ)できる
  • 最適な技術を選択できる

などのメリットがあるのですが、反面、モノリスでは発生しなかった「サービス間の通信」が多数発生します。ネットワークレイヤに限っていえば、すごくややこしくなるんですね。

Kubernetesクラスターにデプロイされるアプリケーションは、このマイクロサービス構成のアプリケーション、しかも大規模なものがデプロイされることが多いので、問題が起きた際のネットワークレベルでの理解・デバッグに時間がかかる、といったことが起きます。

新機能: Container Network Observability

そこで、この「Container Network Observability」という機能が、re:Invent直前にローンチされました。
一言で言うと、ネットワークレイヤのより深い理解、監視、トラブルシューティングに役立つ機能です。
3つの機能で構成されていますので、それぞれご説明していきます。

1. Service map

2025-news-eks-container-network-observability-rev-1.png
Container Network Observability を使用して、EKS クラスター全体のネットワークパフォーマンスとトラフィックをモニタリング | Amazon Web Services ブログ より引用

これはクラスター内のアクセス経路を可視化するツールです。
上記画面ですと、3種類のDeploymentが相互に通信している例が表示されています。以下のようにPodレベルでの可視化も可能です。
2025-news-eks-container-network-observability-rev-2.png
Container Network Observability を使用して、EKS クラスター全体のネットワークパフォーマンスとトラフィックをモニタリング | Amazon Web Services ブログ より引用

2. Flow table(フローテーブル)

先ほどのサービスマップが「誰が誰と話しているか」を把握するためのツールでしたが、こちらは「話す量(アクセス量)」を把握するためのツールです。
先ほどのサービスマップはクラスター内の通信のみを可視化する機能でした。が、こちらのフローテーブルに関しては、「クラスター内の通信」の他に、「AWSサービスへの通信」、それと「AWS以外(外部)への通信」、これらそれぞれ3つの種類のアクセス量をテーブル形式で表示することができます。

flow-table.png
Monitor Kubernetes workload traffic with Container Network Observability - Amazon EKSより転載

このフローテーブルを使うことで、例えば以下が可能になります。

  • クラスター内の通信に関しては、高負荷を発生させているPodの特定
  • AWSサービスへの通信に関しては、AWS利用費増を招いているPodの特定
  • 外部通信に関しては、想定外のサイトへの通信の特定

以下は AWSサービスへの通信を可視化した例です。

aws-service-view.png
Monitor Kubernetes workload traffic with Container Network Observability - Amazon EKSより転載

以下はクラスター内の通信を可視化した例です。

cluster-view.png
Monitor Kubernetes workload traffic with Container Network Observability - Amazon EKSより転載

3. Performance metrics(パフォーマンスメトリクス)

より低レベルなネットワーク関連のシステムメトリクスを提供してくれます。パケット数とかバイト数とかですね。もうひとつ、帯域幅制限,送受信パケット数制限などといったネットワーク制限に引っかかった件数のカウンタも含まれています。

この機能の嬉しい点が、Prometheusが収集可能なOpenMetricsという形式でメトリクスを提供してくれる点です。ですのでPrometheusでメトリクス収集→Grafanaで可視化というKubernetesでよく使われる技術スタックをそのまま使うことができます。

始め方と仕組み

始め方も非常に簡単で、EKSアドオンを1つ追加するだけでOKです。AWSマネジメントコンソールからも数クリックでできます。

addon.png
Container Network Observability を使用して、EKS クラスター全体のネットワークパフォーマンスとトラフィックをモニタリング | Amazon Web Services ブログより転載

裏の仕組みをお伝えすると、この機能は「CloudWatch Network Flow Monitor」という既存のCloudWatchの機能をEKS向けにカスタマイズしたものです。なので裏ではNetwork Flow Monitorリソースが作成されています。エージェントとなるPodがクラスター内にデプロイされて、それがここまでお伝えしたサービスマップやテーブルビューなどの情報を収集してくれますし、パフォーマンスメトリクスもそのエージェントPodが公開します。

料金

気になる料金ですが、そこまで高くないかなという風に思っています。
CloudWatch Network Flow Monitorの料金がかかり、課金対象は2点です。

1. 監視対象となるEKSノード(EC2インスタンス)ごとの時間課金

ノード数が多いほど課金額が増えるということです。スペックの低いノードをいっぱい置くよりは、大きいノードを少なく配置する方が、このツールの料金だけで言うとお安くなるということですね。

2. CloudWatchメトリクス課金

5メトリクス作成される分の課金です。1の課金に比べるとかなり安価です。

料金例

東京リージョンで EKS ノード3台構成の場合の月額料金を試算します。

課金項目 単価 計算式 月額
Network Flow Monitor(ノード時間課金) $0.0069/時間 $0.0069 × 3台 × 730時間 $15.11
CloudWatch メトリクス(5メトリクス) $0.30/メトリクス $0.30 × 5メトリクス $1.50
合計 $16.61

また、最初の12ヶ月は無料利用枠として、10リソースまで(7,300リソース時間/月)が無料になります。ノード3台の場合は全て無料枠に収まります。

課金項目 単価 計算式 月額
Network Flow Monitor(ノード時間課金) - 無料枠内(3台 < 10台) $0.00
CloudWatch メトリクス(5メトリクス) $0.30/メトリクス $0.30 × 5メトリクス $1.50
合計 $1.50

つまり、小規模クラスターであれば初年度は月額わずか$1.50程度で利用開始できます。

以上がContainer Network Observabilityの紹介でした。


続いての機能のご紹介です。

EKS Capabilities

EKS Capabilities

まず、以下のKubernetesの風刺アニメコラ動画をご覧ください。

https://x.com/memenetes/status/1637861860039876624

課題:周辺OSSツールの維持管理が大変

Kubernetesを導入すればうまくいくと思ったが、実態は何をするにしてもOSSツールをインストールしなければならず、その維持管理に追われるカオスな世界が広がっている、という内容の動画でした(と私は理解しています)。

この動画のとおり、Kubernetesの運用は周辺OSSツールの維持管理が大変だというところがあります。ツールごとにインストール作業がありますし、その構成管理にHelmなどの別のツールを習得する必要があったり、アップグレードも定期的に必要…などで運用作業がいっぱいになってしまう、という課題があります。好きなOSSツールを選択できることは、Kubernetesの大きなメリットではありますが…

新機能: EKS Capabilities

そこで「EKS Capabilities」という機能が発表されました。日本語にすると「EKS 機能群」みたいな、かなりざっくりした名前ですね。

こちらはAWSフルマネージドで各種追加機能・ツールを利用できるというものです。保守管理をAWSにお任せして、アップグレードすらもAWSが自動でやってくれます。

現時点で利用できる機能・ツールとして以下の3点があります。今後も増えていくのではないかと予想します。

1. Argo CD

継続的デリバリー(CD)ツールです。GitOpsという、Gitリポジトリとクラスター内の実際のアプリケーションの状態を常に同期させることをするためのツールです。2024年のCNCFのアンケートによると、45%以上のユーザーが本番利用中、もしくは本番利用計画中であるという結果が出たりなど、デファクトスタンダードなツールと言えるのかなと思います。

2. ACK (AWS Controllers for Kubernetes)

Kubernetesリソースと同じ管理方法(YAMLのマニフェストファイル)で、各種AWSリソースもデプロイ・管理できる、というツールです。

Kubernetesリソースについては各アプリケーションチームの責務範囲、AWSリソースはプラットフォームチームの責務範囲というような役割分担を採られている会社も多いかと思います。ただし、アプリケーションの構成要素にAWSリソースが含まれる場合、例えばRDSインスタンスが必要だとか、SQSキューが必要だとか、そんなこともあると思います。ACKを使えば、そういったリソースをアプリケーションチームの扱い慣れた管理形態(YAMLのマニフェストファイル)で定義できるので、アプリケーションチームが管理することが容易になります。

3. kro (Kube Resource Orchestrator)

「クロウ」と読むそうです。

複数のKubernetesリソースをまとめるResourceGraphDefinitionという種別のリソースを定義できます。つまり、複数のKubernetesリソースをまとめて、一つのリソースのように扱える、ということですね。これによりアプリケーションチームの開発者は具体的なKubernetesリソースの詳細を気にする必要がなく、より抽象的なレベルでリソースを扱えるようになります。さらに前述のACKのカスタムリソースをその中に含めれば、AWSリソースも含めた抽象化が可能になります。

kro-1.png
What is kro? | kroより転載。青枠の「Group of Resources」単位でリソースとして扱える。内部の各リソースを意識する必要が無い

一方、セキュリティチームやプラットフォームチームはResourceGraphDefinitionに会社標準構成を適用していけば、全社横展開が容易になります。AWSサービスでいうとService Catalogみたいな感じのツールでしょうか。

もとは2024年11月にAWSが発表した実験的プロジェクトだったのですが、2025年1月にAWS、Microsoft Azure、Google Cloud のオープンなコラボレーションとしてオープンソースプロジェクト化されたと発表がありました。3大クラウドプロバイダーが協力して取り組んでいる、というのは注目ですね。

料金

2種類の時間課金が発生します。

1. Base charge

  • 各機能を有効にするだけで発生する費用。

2. Usage charge

  • その機能管理下にあるリソースが増えるごとに増える時間課金。例えばArgo CDの場合Applicationの数が Usage charge時間単価に乗算されます。

私が現在携わっているプロジェクトでもArgo CDを使用しており、Fargateノード上にデプロイしています。このプロジェクトでCapabilitiesへ移行した場合のコストを試算したところ、一部利用できなくなる機能があるものの、結構なコスト削減が期待できることがわかりました。詳細は以下をご参照ください。

https://dev.classmethod.jp/articles/migrate-argocd-from-fargate-to-eks-capabilities/

参考情報

この記事をシェアする

FacebookHatena blogX

関連記事