Amazon Web Services ブログ
フルマネージド Amazon EKS MCP Server (プレビュー) の紹介
この記事は Introducing the fully managed Amazon EKS MCP Server (preview) (記事公開日: 2025 年 11 月 21 日) を翻訳したものです。
複雑な kubectl コマンドや深い Kubernetes の専門知識の代わりに、シンプルな会話を通じて Amazon Elastic Kubernetes Service (Amazon EKS) クラスターを管理する方法を学びましょう。この記事では、新しいフルマネージド EKS Model Context Protocol (MCP) Server (プレビュー) を使用して、深い Kubernetes の専門知識を必要とせず、自然言語でアプリケーションのデプロイ、問題のトラブルシューティング、クラスターのアップグレードを行う方法を紹介します。複数ステップの手動タスクをシンプルな自然言語リクエストに変換する会話型 AI の実際のシナリオを説明します。
Kubernetes ワークロードを管理するチームには、コンテナオーケストレーション、インフラストラクチャ、ネットワーキング、セキュリティにわたる専門知識が必要です。大規模言語モデル (LLM) は開発者がコードを書いたりワークロードを管理したりするのに役立ちますが、リアルタイムのクラスターアクセスがなければ制限されます。古いトレーニングデータに基づく一般的な推奨事項は、実際のニーズを満たしません。Model Context Protocol (MCP) は、AI モデルにクラスターデータへのリアルタイムの安全なアクセスを提供することで、この問題を解決します。
MCP は、AI モデルがより良いコンテキストのために外部ツールやデータソースに安全にアクセスできるようにするオープンソース標準です。EKS クラスターのリアルタイムでコンテキストに応じた知識で AI アプリケーションを強化する標準化されたインターフェースを提供し、開発から運用まで、アプリケーションライフサイクル全体を通じてより正確でカスタマイズされたガイダンスを可能にします。今年初め、AWS は MCP プロトコルのリリースから数か月以内に、MCP サーバーを発表した最初のマネージド Kubernetes サービスプロバイダーの 1 つでした。お客様は EKS と Kubernetes リソース管理のために、この EKS MCP Server をマシンにインストールできました。この初期のローカルインストール可能なバージョンの EKS MCP Server により、私たちはアプローチを迅速に検証し、貴重なお客様のフィードバックを収集することができ、それが今日の発表に直接つながっています。
私たちが受け取った最も一貫したフィードバックは、クラウドホスト型のフルマネージド EKS MCP Server の必要性についてでした。本日、AWS はフルマネージド Amazon EKS MCP Server (プレビュー) をリリースしました。新しいホスト型 EKS MCP Server は、本番環境に不可欠な機能で以前のリリースを改善しています。
- インストールとメンテナンスの排除: バージョン更新の管理やローカルサーバーの問題のトラブルシューティングは不要です。軽量プロキシを通じてホスト型 EKS MCP Server エンドポイントに接続するように AI アシスタントを設定することで、新しいツール、機能、バグ修正を自動的に受け取ります。
- 一元化されたアクセス管理: AWS Identity and Access Management (IAM) との深い統合により、サーバーへのアクセスを制御する一元化された安全な方法が提供されます。すべてのリクエストは AWS Signature Version 4 (SigV4) を使用して署名され、既存の AWS 認証情報と IAM ポリシーとのシームレスな統合が可能になります。
- 強化されたトラブルシューティング: 大規模に数百万の Kubernetes クラスターを管理した運用経験から構築されたナレッジベースへのアクセス。
- 強化された監視と可視性: AWS CloudTrail 統合により、ホストされたサービスを通じて行われたすべてのツール呼び出しがキャプチャされ、AI 支援操作の詳細な監査証跡とコンプライアンスレポートが可能になります。
フルマネージド EKS MCP Server の目標は、Kiro (IDE と CLI)、Cursor、Cline などの AI を活用した開発ツールを使用している場合でも、EKS クラスターとインターフェースする必要がある独自のエージェントを構築している場合でも、エージェント体験を可能にすることです。この標準化されたインターフェースにより、MCP 互換の AI ツールは、すぐに強力な EKS ガイダンスと自動化を提供できるようになりました。
ホスト型 MCP サーバーに加えて、Amazon Q とのより深い統合を通じて、Amazon EKS コンソールのトラブルシューティング体験も大幅に改善しています。強化されたコンソールでは、オブザーバビリティダッシュボードのエラーメッセージのすぐ横に AI を活用したトラブルシューティングオプションが表示されます。ワンクリックで根本原因を診断し、修正手順を確認できます。クラスター、コントロールプレーン、ノードヘルスの問題を調査している場合でも、問題の一覧または詳細ビューから直接「Amazon Q で検査」をクリックして調査を開始できます。コンソール統合により、クラスターのヘルスと今後のアップグレードに関する重要な詳細が明らかになり、本番ワークロードに影響を与える前に問題を発見できます。
Amazon EKS MCP Server ツール
EKS MCP Server は、問題の診断と EKS クラスターとその Kubernetes コンポーネントの両方を制御するための専門ツールを提供します。これらのツールは次のカテゴリに分類されます。
- クラスター管理ツール – EKS クラスターの作成と管理
- Kubernetes リソース管理 – Kubernetes コマンドに依存せずに EKS クラスター内の Kubernetes リソースを操作および管理します。
- アプリケーションデプロイ – アプリケーションをデプロイするための Kubernetes マニフェストを生成します。
- トラブルシューティング – 大規模に Kubernetes クラスターを実行する AWS の運用知識から得られたトラブルシューティングガイドを提供します。
- ドキュメントとナレッジベース – 最新の情報とベストプラクティスのために AWS ドキュメントとナレッジベースを検索します。
ツールの完全なリストについては、EKS MCP Server ユーザーガイドをご覧ください。
Amazon EKS MCP Server の使用開始
前提条件
AWS 設定: この機能を使用するには、AWS CLI がマシンにインストールされ、設定されている必要があります。MCP 設定で使用するプロファイルを設定するには、ドキュメント「Configuration and credential file settings in the AWS CLI」に従ってください。このブログ記事のシナリオでは、AWS プロファイルは us-west-2 リージョンへのアクセスで設定する必要があります。
MCP クライアント: MCP をサポートする多くのエージェントツールの 1 つを使用できます。このブログ記事では、クライアントとして Kiro CLI を使用します。Kiro CLI の MCP クライアント設定をセットアップするには、MCP 設定ファイル仕様に従ってください。
Python 環境: Python の uv パッケージマネージャーがインストールされている必要があります。パッケージマネージャーは mcp-proxy-for-aws パッケージを自動的にダウンロードして実行するため、個別にインストールする必要はありません。MCP プロキシにより、クライアントは AWS SigV4 認証を使用してリモートの AWS ホスト型 MCP サーバーに接続できます。
AWS Identity and Access Management (IAM) アクセス許可: AWS プロファイルには、EKS クラスターの読み取り、CloudWatch ログへのアクセス、Kubernetes リソースの表示のための EKS 関連の IAM アクセス許可が必要です。AWS プロファイルへのアクセスを許可する際は、最小権限の原則に従ってください。MCP Server への接続に使用されるロールには、初期化と利用可能なツールに関する情報の取得のために IAM eks-mcp:InvokeMcp のアクセス許可が必要です。読み取り専用ツールの使用には eks-mcp:CallReadOnlyTool が必要で、フルアクセス (書き込み) ツールの使用には eks-mcp:CallPrivilegedTool が必要です。
設定
フルマネージド EKS MCP Server アーキテクチャは、AWS SigV4 認証を使用して MCP クライアントを AWS サービスに安全に接続します。次の図は通信フローを示しています。
図 1: AI クライアントと AWS サービス間の MCP 通信フローを示すアーキテクチャ図
Kiro CLI の設定例を次に示します。
エンドポイント URL https://eks-mcp.{AWS_REGION}.api.aws/mcp の us-west-2 リージョンに注目してください。これは MCP Server がホストされているリージョンです。--profile フラグは、MCP Server への接続に使用されるローカル AWS プロファイルを参照します。このフラグはオプションで、環境変数 AWS_PROFILE を使用できます。--region フラグは、作業対象の EKS クラスターをスコープするリージョンを参照します。このフラグはオプションで、環境変数 AWS_REGION を使用できます。--read-only フラグを使用して、読み取り専用ツールのみが許可されることを示すことができます。
ツールアクセスレベル
EKS MCP Server は 2 つのアクセスレベルをサポートしています。
- 読み取り専用モード (
--read-onlyフラグ): すべての読み取り操作とドキュメントツールへのアクセスを提供 - フルアクセスモード: すべての読み取り専用ツールに加えて、クラスター作成、リソース管理、ポリシー変更などの書き込み操作を含む
各ツールは、特定の aws eks または kubectl CLI コマンドを置き換えるように設計されており、MCP プロトコルを通じた EKS の管理のためのより統合された体験を提供します。
シナリオ 1: 会話型 AI による EKS クラスターのアップグレード
EKS インサイトを使用してクラスターのアップグレード準備状況を評価する EKS MCP Server の機能は重要な機能です。このセクションでは、EKS クラスターが Kubernetes バージョンのアップグレードの準備ができているかどうかを確認する方法を示します。
アップグレード準備状況の確認
プロセスには 3 つの簡単なステップが含まれます。
- 利用可能なクラスターを一覧表示して、確認するクラスターを特定する
- アップグレード準備状況のインサイトを取得して互換性を評価する
- EKS ドキュメントを検索してタイムラインを特定する
実際の例を見てみましょう。
1. EKS クラスターの一覧表示
まず、次のプロンプトから始めます。
エージェントは list_eks_resources を使用して利用可能なクラスターを検出し、describe_eks_resource を介して設定を取得します。
図 2: 利用可能な EKS クラスター「my-auto-cluster」を表示するターミナル出力のスクリーンショット
これは、評価に利用可能な「my-auto-cluster」という名前のクラスターが 1 つあることを示しています。
2. アップグレード準備状況インサイトの確認
次に、エージェントは UPGRADE_READINESS カテゴリで get_eks_insights ツールを使用して、クラスターのアップグレード準備状況を評価します。
図 3: EKS クラスターのアップグレード準備状況インサイトを示すターミナル出力
3. EKS ドキュメントの検索
最後に、エージェントはアップグレードのタイムラインと価格について EKS ドキュメントを検索します。
図 4: アップグレードタイムラインの EKS ドキュメント検索結果を表示するターミナル出力
アップグレード準備状況レポート
インサイト分析に基づいて、包括的なアップグレード準備状況レポートを次に示します。
図 5: すべての互換性チェックが合格していることを示す包括的なアップグレード準備状況レポート
クラスター「my-auto-cluster」は Kubernetes 1.33 へのアップグレードの準備が完全に整っています。すべての重要な互換性チェックが合格しており、アップグレードを阻害する問題は特定されませんでした。
アップグレードに EKS MCP を使用する主な利点
- 自動評価: 複数のコンポーネントを手動で確認する必要がありません
- 包括的なカバレッジ: アドオン、ノードの互換性、クラスターのヘルスを評価します
- 明確なガイダンス: 各チェック結果の具体的な理由を提供します
- プロアクティブな警告: 問題がブロッカーになる前に潜在的な問題を特定します
- EKS Auto Mode の認識: 最新の EKS デプロイパターンを理解します
アップグレード前に互換性を自動的にチェックすることで、準備にかかる時間が短縮され、デプロイの失敗が減少します。
シナリオ 2: 自然言語によるアプリケーションのデプロイ
EKS MCP Server は、自然言語プロンプトを通じて高レベルのワークフローを可能にします。たとえば、ユーザーは次のようにリクエストできます。
エージェント (Kiro CLI) は、このワークフローを完了するために複数の EKS MCP ツールを調整します。
主要な EKS MCP ツールの動作
1. アプリケーションマニフェストの生成 generate_app_manifest ツールは、最小限の入力で本番環境対応の Kubernetes マニフェストを作成し、デプロイ、サービス、ロードバランサーを自動的に設定します。
図 6: Web デプロイ用のアプリケーションマニフェスト生成を示すターミナル出力
2. 効率化されたデプロイ apply_yaml ツールは、複雑な kubectl ワークフローを置き換えて、単一の操作でマルチリソースの YAML 設定をデプロイします。
図 7: Kubernetes クラスターへの YAML デプロイを示すターミナル出力
3. リソースの検出とステータス list_k8s_resources と read_k8s_resource ツールを組み合わせて、インテリジェントなフィルタリングでデプロイされたリソースを検出し、詳細な設定を取得します。
図 8: デプロイされたアプリケーションのリソース検出とステータスを示すターミナル出力
4. アプリケーションログとイベント get_pod_logs と get_k8s_events ツールを組み合わせて、コンテナログと Kubernetes イベントの両方を表示する包括的なデバッグ機能を提供します。
図 9: アプリケーションログと Kubernetes イベントを表示するターミナル出力
5. CloudWatch オブザーバビリティ get_eks_metrics_guidance、get_cloudwatch_metrics、get_cloudwatch_logs ツールを組み合わせて、完全なオブザーバビリティのセットアップと監視を提供します。
図 10: CloudWatch オブザーバビリティメトリクスとログのセットアップを示すターミナル出力
デプロイの概要
完全なデプロイワークフローは、EKS MCP ツールがシームレスに連携する力を示しています。
図 11: マニフェストから監視までの完全なワークフローを示すデプロイ概要
EKS MCP Server は、複数ステップのデプロイを単一の会話リクエストに変換し、各段階で情報を提供しながら、オーケストレーション、エラー、監視を処理します。
結果として、AWS の Network Load Balancer を介してアクセス可能な完全なウェブアプリケーションができあがりました。EKS MCP サーバーがどのように複雑なデプロイワークフローを簡単な会話型のリクエストに簡略化できるかがわかります。
シナリオ 3: インフラストラクチャの問題のトラブルシューティング
問題が Kubernetes と AWS インフラストラクチャの境界をまたぐ場合、EKS MCP Server は効果的に診断します。
エージェントは、問題を診断して解決するために複数の EKS MCP ツールを調整しました。
主要な EKS MCP ツールの動作
1. サービスステータス分析 read_k8s_resource ツールは LoadBalancer サービスの設定とステータスを取得し、サービスが作成されたにもかかわらず外部 IP が割り当てられていないことを明らかにしました。
図 12: LoadBalancer サービスステータス分析を示すターミナル出力
2. イベント調査 get_k8s_events ツールはサービスの Kubernetes イベントを調査し、サブネットに必要な kubernetes.io/role/elb タグが欠落していることを示す重要なエラーメッセージを発見しました。
図 13: サブネットタグの問題を明らかにする Kubernetes イベントを表示するターミナル出力
3. トラブルシューティングナレッジベース search_eks_troubleshooting_guide ツールは、LoadBalancer サービスの問題とサブネットタグの要件に関するガイダンスについて、専門の EKS トラブルシューティングナレッジベースを検索しました。
図 14: EKS トラブルシューティングガイドの検索結果を示すターミナル出力
4. インフラストラクチャ分析 get_eks_vpc_config ツールは包括的な VPC とサブネット設定の詳細を取得し、欠落しているタグが必要な特定のパブリックサブネットを特定しました。
図 15: VPC とサブネット設定の詳細を表示するターミナル出力
トラブルシューティングの概要
完全なトラブルシューティングワークフローは、EKS MCP ツールが Kubernetes と AWS ドメインをどのように橋渡しするかを示しています。
図 16: 診断手順と解決策を示すトラブルシューティングワークフローの概要
これは、EKS MCP Server が通常 Kubernetes と AWS インフラストラクチャの両方の専門知識を必要とする包括的なトラブルシューティングを可能にし、複雑な診断ワークフローを単一の会話インターフェースに統合する方法を示しています。
Amazon Q による強化された EKS コンソール体験
Amazon EKS は、Amazon Q 統合を通じて、CLI や IDE を超えてコンソールに直接エージェント体験をもたらします。「Amazon Q で検査」機能は、オブザーバビリティダッシュボード全体に表示され、トラブルシューティングと分析のためのコンテキストに応じた AI 支援を提供します。
統合された AI 支援
「Amazon Q で検査」ボタンは、複数のコンソールセクションに戦略的に配置されています。
クラスターのヘルスの問題: ヘルスの問題が検出されると、「検査」をクリックして、無効化された KMS キーや設定の問題などの問題に対する AI を活用した分析と修復の提案を取得できます。
図 17: クラスターのヘルスの問題に対する「Amazon Q で検査」ボタンを示す EKS コンソールのスクリーンショット
アップグレードインサイト: アップグレード準備状況チェックの場合、検査機能は互換性の問題、バージョンスキューの問題、推奨されるアクションの詳細な説明を提供します。
図 18: アップグレードインサイトの警告に対する「Amazon Q で検査」ボタンを示す EKS コンソールのスクリーンショット
ノードヘルスのモニタリング: 個々のノードの問題は、検査機能を通じて分析でき、ノードのステータスと基盤となるインフラストラクチャの問題を関連付けます。
図 19: ノードヘルスのステータスに対する「Amazon Q で検査」ボタンを示す EKS コンソールのスクリーンショット
オブザーバビリティデータ: 破損した Webhook、HTTP エラーパターン、API サーバーの問題などの複雑なオブザーバビリティデータは、AI を活用した説明を通じてよりアクセスしやすくなります。
図 20: 破損した Kubernetes Webhook に対する「Amazon Q で検査」を示す EKS コンソールのスクリーンショット
コンテキストインテリジェンス
検査機能は Amazon Q の機能を活用し、コンソールのコンテキスト内で直接インサイトを提示します。これにより、ツールを切り替えたり、異なる AWS サービス間で情報を手動で関連付けたりする必要がなくなります。視覚的なダッシュボードから会話型トラブルシューティングへシームレスに移行でき、さまざまなレベルの Kubernetes 専門知識を持つチームにとって EKS の管理がより直感的になります。
まとめ
プレビュー版の Amazon EKS MCP Server は、自然言語を通じて複雑な操作をアクセス可能にすることで、チームが Kubernetes とやり取りする方法を変革します。プレビュー版の EKS MCP Server は、AWS GovCloud (米国) リージョンと中国リージョンを除くすべての AWS 商用リージョンで利用できます。複数のドメインにわたる深い専門知識を必要とする代わりに、チームは Kubernetes と AWS サービスをシームレスに橋渡しする会話インターフェースを通じて EKS クラスターを管理できるようになりました。
会話型の EKS の管理を体験する準備はできましたか?この記事のセットアップ手順を使用して、環境で EKS MCP Server を設定することから始めましょう。読み取り専用操作から始めてクラスターインサイトを探索し、チームが会話インターフェースに慣れるにつれて、徐々に完全な管理機能に拡張してください。Amazon EKS MCP Server の詳細については、Amazon EKS ユーザーガイドをご覧ください。
翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文はこちらです。