公開更新 AIエージェント・MCP

Amazon EKS MCP Serverとは？ホスト型とOSS版の違い・接続手順と権限設計【2026年10月】

Amazon EKS MCP Serverとは？ホスト型とOSS版の違い・接続手順と権限設計【2026年10月】

Amazon EKS MCP Serverは、KiroやClaude Code、CursorといったAIアシスタントに、EKSクラスターの実データ（Podのログ、イベント、Insights、VPC構成など）を読ませるためのMCPサーバーです。現在は、AWSがクラウド側で動かすホスト型（2025年11月21日からプレビュー）と、利用者のPCで起動するOSS版 awslabs.eks-mcp-serverの2つがあります。名前は同じでも、ツール名・既定の権限・扱える入力が違うため、混同したまま設定すると「読み取り専用のつもりで書き込みツールが開いている」状態になりかねません。この記事では2026年10月2日時点の公式ドキュメントと、OSS版0.2.1・mcp-proxy-for-aws 1.7.0を手元で動かした結果をもとに、選び方・接続手順・IAMの組み方・本番前に確かめる制約を整理します。

まとめ：EKS MCP Serverの選び方と安全に使うための要点

新しく始めるならホスト型を選び、IAMで書き込みを止めるのが基本です。要点は次の5つです。

  • 提供形態：ホスト型はエンドポイント https://eks-mcp.{region}.api.aws/mcp に、ローカルのプロキシ mcp-proxy-for-aws 経由でSigV4署名して接続します。2026年10月2日時点でも公式ドキュメントは「preview release」と明記しています。
  • 既定の権限が逆：OSS版は何も付けなければ読み取り専用で、書き込みは --allow-write で解禁します。ホスト型のプロキシは何も付けなければ全ツールが有効で、--read-only を付けたときだけ書き込み系を隠します。
  • 本当の歯止めはIAM：ホスト型では eks-mcp:CallPrivilegedTool を持たないロールなら書き込みツールを呼べません。AWS管理ポリシー AmazonEKSMCPReadOnlyAccess にはこのアクションが入っていないので、まずはこれだけを付けます。
  • Kubernetes APIへの書き込みはパブリックエンドポイントのクラスターだけ：ホスト型のKubernetes API読み取り操作はプライベートクラスターにも届きますが、Kubernetes API書き込み操作は endpointPublicAccess=true のクラスターにしか届きません。
  • Secretを渡さない：応答中のトークンや証明書は HIDDEN_FOR_SECURITY_REASONS に置き換えられますが、AWSは「MCPツールでKubernetes Secretを作らない」ことも求めています。

Amazon EKS MCP Serverの役割と2つの提供形態

MCP（Model Context Protocol）は、AIアプリケーションが外部のツールやデータへ同じ作法でつながるための規格です（規格そのものはMCP（Model Context Protocol）の仕組みを解説した記事で扱っています）。EKS MCP Serverはその「EKS用の受け口」で、AIがkubectlやAWS CLIの代わりに、決められたツールを通してクラスターの状態を読み、許可されていれば変更を加えます。

AIにクラスターの実データを渡すツール群の中身

公式ドキュメントはツールの用途を、クラスター管理、Kubernetesリソースの管理、トラブルシューティング、ドキュメント検索の4つに分けています。たとえば「Runningでない Pod を挙げて」と頼むと、AIは list_k8s_resources でPod一覧を取り、get_pod_logs で直近100行（既定値）のログを読み、get_k8s_events でイベントを突き合わせてから原因を答えます。AIの知識だけで推測するのと違い、クラスターの今の状態を根拠にできるのが利点です。search_eks_troubleshooting_guide のように、AWSが運用知見から作ったトラブルシューティングの知識ベースを引くツールもあります。

2025年5月のOSS版と2025年11月のホスト型の違い

先に出たのはOSS版で、PyPIの awslabs.eks-mcp-server は2025年5月29日に0.1.1が公開されました。2026年9月8日公開の0.2.1が最新で、ここまでに37版が出ています。ホスト型は2025年11月21日にAWSが「フルマネージドのEKS MCP Server（プレビュー）」として発表したもので、同日にAWS管理ポリシー AmazonEKSMCPReadOnlyAccess も追加されました。

項目 ホスト型（プレビュー） OSS版 awslabs.eks-mcp-server
動く場所 AWSのクラウド 利用者のPC（uvxで起動）
接続 mcp-proxy-for-aws＋SigV4 stdioで直接起動
ツール数 20（読み取り16・書き込み4） 16（IAMモード）／7（kubeconfigモード）
既定の権限 全ツール有効 読み取り専用
権限の切り替え IAMの3アクション＋--read-only --allow-write／--allow-sensitive-data-access
YAMLの渡し方 本文を文字列で渡す ローカルのファイルパスを渡す
監査 CloudTrailに記録 自前でログを取る
更新 自動 @latestで起動時に取得

同じ名前で全AWSサービスを扱う「AWS MCP Server」もありますが、こちらはAPI呼び出しとドキュメント検索を束ねた汎用サーバーで、EKS専用のツールは持ちません。違いはAWS MCP ServerのGA版の接続手順と全ツール・権限設計を解説した記事で確認できます。

ホスト型EKS MCP Serverの接続手順

ホスト型ではサーバーをインストールしません。手元で動くのは、ローカルのAWS認証情報で要求にSigV4署名を付けてエンドポイントへ中継する mcp-proxy-for-aws（2026年9月15日公開の1.7.0が最新）だけです。

前提となるAWS CLI・Python・uvの準備

公式ガイドの前提は、認証情報を設定済みのAWS CLI、Python 3.10以上、uvの3つです。なお、mcp-proxy-for-aws 1.7.0がPyPIで宣言しているPython要件は3.10以上3.15未満です。uvxが実行環境を用意するので、事前の pip install は要りません。@latest を付けると起動時に最新版を確認しますが、取得済みのパッケージはキャッシュから再利用されます。以下の eks-readonly は、読み取り専用ポリシーを付けたロール用に自分で作るプロファイル名の例です。

python3 --version   # 3.10以上
uv --version
aws configure list --profile eks-readonly  # 後続の設定と同じプロファイルを確認
aws sts get-caller-identity --profile eks-readonly --region us-west-2

mcp-proxy-for-awsを指定するMCP設定JSON

KiroのIDEとCLIはどちらも、ユーザー単位なら ~/.kiro/settings/mcp.json、ワークスペース単位なら .kiro/settings/mcp.json に書きます。CursorやClineも同じ mcpServers 形式です。最初は --read-only を付けた形から始めます。

{
  "mcpServers": {
    "eks-mcp": {
      "disabled": false,
      "type": "stdio",
      "command": "uvx",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://eks-mcp.us-west-2.api.aws/mcp",
        "--service", "eks-mcp",
        "--profile", "eks-readonly",
        "--region", "us-west-2",
        "--read-only"
      ]
    }
  }
}

リージョンの指定は2か所あり、意味が違います。AWSのブログによると、URLの eks-mcp.{region} はMCPサーバーが動いているリージョン、--region は操作するクラスターがあるリージョンです。Windowsでは "--from", "mcp-proxy-for-aws@latest", "mcp-proxy-for-aws.exe" の順に書き換えます。

Claude Codeなら、設定ファイルを編集せずにコマンド1行で登録できます。-- より後ろがプロキシの起動コマンドです。

claude mcp add eks-mcp -- uvx mcp-proxy-for-aws@latest \
  https://eks-mcp.us-west-2.api.aws/mcp \
  --service eks-mcp --profile eks-readonly --region us-west-2 --read-only

Amazon Q Developer CLIの手順がKiro CLIへ移った点

EKSのユーザーガイドは今も「Option A: Amazon Q Developer CLI」を先頭に置き、設定ファイルを ~/.aws/q/mcp.json としています。ところがQ Developer CLIは2025年11月24日の自動更新でKiro CLIに置き換わっており、Amazon Q Developerも2026年5月15日に、IDEプラグインからの無料枠アカウント作成とサブスクリプションの新規作成を停止しました。これから設定するなら、AWSのブログと同じくKiro CLIの ~/.kiro/settings/mcp.json を使ってください。KiroそのものはKiroの機能と料金を解説した記事にまとめています。

OSS版 awslabs.eks-mcp-server の起動とフラグ

OSS版はホスト型の前身で、今もPyPIで更新が続いています。プレビュー段階のホスト型を社内規程で使えない場合や、OIDCでクラスターに入る環境では、こちらが選択肢になります。

既定の読み取り専用でも16ツールすべてが見える実測結果

0.2.1をuvxで起動し、MCPの tools/list を投げてツール一覧を取ったところ、フラグなし・--allow-write あり・両フラグありのいずれでも、返ってきたツールは同じ16個でした。OSS版の読み取り専用は「書き込みツールを隠す」のではなく、「呼ばれたときに断る」作りです。実際、フラグなしで呼ぶと次の応答が返りました。

apply_yaml          → Operation apply_yaml is not allowed without write access
manage_eks_stacks   → Operation generate is not allowed without write access
manage_k8s_resource → Operation delete is not allowed without write access
get_pod_logs        → Access to pod logs requires --allow-sensitive-data-access flag
manage_k8s_resource（kind=Secret, read）
                    → Access to Kubernetes Secrets requires --allow-sensitive-data-access flag

AIからは書き込みツールが見えるので、「apply_yamlで直します」と提案してから失敗する、というやり取りが起こります。挙動としては安全側ですが、書き込みツールの呼び出しを避けたいなら、クライアント側でも対象ツールを無効にします。ただし、ツールを無効にしてもAIが文章で変更案を示すこと自体は止められません。

2つのフラグで解禁される操作

OSS版のREADMEによると、2つのフラグはどちらも既定でfalseです。解禁されるものは次のとおりです。

フラグ 解禁される操作
--allow-write apply_yaml、generate_app_manifest
--allow-write manage_eks_stacks（generate・deploy・delete）
--allow-write manage_k8s_resource（create・replace・patch・delete）
--allow-write add_inline_policy
--allow-sensitive-data-access get_pod_logs、get_k8s_events、get_cloudwatch_logs
--allow-sensitive-data-access get_eks_vpc_config、get_eks_insights
--allow-sensitive-data-access manage_k8s_resourceでのSecret読み取り

注意したいのは、READMEのQuickstartにあるKiro・Cursor・VS Codeのワンクリック導入ボタンが、両方のフラグを付けた設定を書き込むことです。ボタンで入れた場合は、設定ファイルを開いてフラグを消してから使い始めてください。また、ローカルで動くOSS版ではマニフェストをファイルとして扱います。apply_yaml の必須引数は yaml_path（ローカルのファイルパス）、generate_app_manifest の必須引数は output_dir です。--allow-write 付きで generate_app_manifest を呼ぶと、Deploymentと aws-load-balancer-scheme: internal 注釈付きのLoadBalancer型Serviceが web-manifest.yaml として書き出されました。

kubeconfigモードで7ツールに減る条件

既定のIAMモードでは、Kubernetes APIに入れるのは「そのクラスターを作ったIAMプリンシパル」か「EKSアクセスエントリーが設定されたプリンシパル」だけです。OIDCなどkubeconfigで認証している環境では、--auth-mode kubeconfig（または環境変数 EKS_AUTH_MODE=kubeconfig）で起動します。このモードではAWSのAPIを使うツールが登録されず、手元で数えると16個から7個に減りました。残るのはlist_k8s_resources、get_pod_logs、get_k8s_events、list_api_versions、manage_k8s_resource、apply_yaml、generate_app_manifestです。CloudWatch・IAM・Insights・トラブルシューティング知識ベースは使えなくなります。

ホスト型とOSS版で異なるツール名と引数

ホスト型のツールは20個です。読み取り16個のうち、search_eks_documentation、describe_eks_resource、list_eks_resources、read_k8s_resource の4つはOSS版にありません。逆に、OSS版の search_eks_troubleshoot_guide はホスト型では search_eks_troubleshooting_guide と名前が変わっています。プロンプトやエージェントの手順書にツール名を直接書いているなら、移行時に書き換えが必要です。

用途 ホスト型 OSS版
Kubernetesリソース1件の取得 read_k8s_resource manage_k8s_resource（read）
EKSリソースの一覧・詳細 list_eks_resources／describe_eks_resource なし
EKSドキュメント検索 search_eks_documentation なし
トラブルシューティングガイド検索 search_eks_troubleshooting_guide search_eks_troubleshoot_guide
YAMLの適用 apply_yaml（yaml_content） apply_yaml（yaml_path）
CloudFormationでのクラスター作成 manage_eks_stacks（template_content） manage_eks_stacks（template_file）
マニフェスト生成 generate_app_manifest（読み取り扱い） generate_app_manifest（書き込み扱い）

ホスト型の書き込みツールは manage_k8s_resource、apply_yaml、manage_eks_stacks、add_inline_policy の4つです。なお、旧版のこの記事で紹介していた describe_k8s_resource と delete_k8s_resource は、どちらの版にも存在しません。リソースの削除は manage_k8s_resource の operation: delete で行います。

EKS MCP Serverの権限設計：IAMとKubernetes側アクセス

ホスト型の権限は、MCPサーバー自体を使う許可と、その先でEKS・EC2・CloudWatchなどを読み書きする許可の2層で考えます。

eks-mcpの3アクションと読み取り専用の管理ポリシー

MCPサーバーへの許可は3つのアクションで分かれています。

アクション 必要になる場面
eks-mcp:InvokeMcp 初期化とツール一覧の取得
eks-mcp:CallReadOnlyTool 読み取りツールの呼び出し
eks-mcp:CallPrivilegedTool 書き込みツールの呼び出し

AmazonEKSMCPReadOnlyAccess（2026年2月12日編集のv3が既定）は、このうち InvokeMcp と CallReadOnlyTool に加えて、eksのDescribe・List系と eks:AccessKubernetesApi、IAMロールとポリシーの参照、VPC・サブネット・ルートテーブルの参照、logs:StartQuery／logs:GetQueryResults、cloudwatch:GetMetricData、sts:GetCallerIdentity を含みます。CallPrivilegedTool は入っていません。プロキシの --read-only は手元の設定ファイル1行で外せますが、IAMの拒否は手元から外せません。AIに設定ファイルを書き換えられる環境では、IAMのほうを本当の境界と考えてください。ただしIAMは付与された許可の合算で判定されるので、読み取り専用ポリシーを付けても、同じロールに付いた別ポリシーの書き込み許可は消えません。利用ロールには他のポリシーを付けず、権限の追加や高権限ロールの引き受け（sts:AssumeRole）も許さない設計にします。IAMのユーザーやロールを人ごとに配る代わりに、IAM Identity Centerの権限セットへこの管理ポリシーを付ける方法もあります。

書き込み用ポリシーに含まれる削除系とiam:PassRole

書き込み用のAWS管理ポリシーはありません。公式の導入手順は EKSMcpWriteManagementPolicy というカスタマー管理ポリシーを自分で作る方式で、その中には eks:DeleteCluster、ec2:DeleteVpc などの削除系、iam:CreateRole／iam:PutRolePolicy、eks.amazonaws.com と ec2.amazonaws.com に限った iam:PassRole、eks-mcp:* が入っています。AWS自身が高リスクの権限を含むと明記しており、理由は manage_eks_stacks がVPCごとクラスターを作って消すためです。クラスターを作らせないなら、この雛形から cloudformation:*・ec2:Create*／ec2:Delete*・iam:CreateRole 系を外し、eks-mcp:CallPrivilegedTool とKubernetes APIの権限だけを足す構成にします。

Kubernetes側の認可とアクセスエントリー

IAMで eks:AccessKubernetesApi を許可しても、Kubernetes APIの中で何ができるかは別に決まります。OSS版のREADMEは、IAMモードでKubernetes APIの操作が通るのは「プリンシパルがクラスターの作成者」か「アクセスエントリーが設定されている」場合だけだと明記しています。認可エラーが出たら、まず aws eks list-access-entries --cluster-name <クラスター名> で自分のロールが登録されているかを確認します。読み取りだけを許すなら、アクセスポリシーに AmazonEKSViewPolicy を名前空間単位で関連付けるのが最小構成です。

本番クラスターにつなぐ前に確かめる制約

Kubernetes API書き込み操作のパブリックエンドポイント制約

ホスト型のツールリファレンスは、読み取り系のKubernetes API操作はプライベートとパブリックの両方のクラスターに届く一方、書き込み系は「as of today」パブリッククラスター（endpointPublicAccess=true）にしか届かない、と書いています。本番をプライベートエンドポイントのみにしている構成では、ホスト型からKubernetes APIを通じて本番リソースを書き換えることはできません。読み取り専用で使うと割り切れるなら、これはむしろ好都合です。

CloudTrailに残る呼び出しの範囲

EKSのユーザーガイドは、CloudTrailに記録されるのは「初期化とフルアクセス（書き込み）ツールの呼び出し」だとしています。発表時のブログは「すべてのツール呼び出し」と書いていたので、記述が食い違います。読み取りツールの呼び出しまで監査証跡に必要なら、導入前にCloudTrailのイベント履歴を実際に見て、どの呼び出しが残るかを確かめてください。OSS版にはこの仕組みがなく、記録はクライアント側のログに頼ることになります。

応答の秘匿化とSecretを扱わない運用

ホスト型は、ログやリソース記述などすべての応答で、トークンや証明書によくある形の文字列を HIDDEN_FOR_SECURITY_REASONS に置き換えます。ただしパターンに合うものだけです。公式の注意事項は、apply_yamlに渡すYAMLやプロンプトに秘密情報を入れないこと、MCPツールでKubernetes Secretを作らないこと（秘密の値をモデルに渡すことになるため）を挙げ、代わりにSecrets ManagerやParameter Store、IRSAを使うよう求めています。また、YAMLの中身はKubernetes APIの検証に任せており、サーバー独自の検証はしません。

manage_eks_stacksが消せるスタックの範囲

manage_eks_stacks のdeployとdeleteは、このツール自身が作り CreatedBy=EksMcpServer タグが付いたCloudFormationスタックにしか効きません。既存のIaCで作ったスタックを、manage_eks_stacksが消すことはありません。ただしこの制約は同ツールの対象スタックに限ったもので、書き込み用ポリシーに eks:DeleteCluster が入っていれば、別のAWS APIやツールを経由した削除までは防げません。既存クラスターの削除防止はIAM側で設計します。一方で、AIに作らせたクラスターは自社のTerraformやCDKの管理外にできあがります。クラスター作成は15〜20分かかる操作でもあるので、検証用の使い捨て環境に限るのが無難です。IaCで組むならTerraform MCP Serverの導入手順とtoolsetの権限設計を解説した記事の構成と組み合わせるほうが、変更の履歴が残ります。

EKS MCP Serverを採用すべき場面と見送る場面

向いているのは、障害調査の一次切り分けを読み取り専用で回す用途です。CrashLoopBackOffのPodについてログ・イベント・Insights・CloudWatchメトリクスを横断して読む作業をAIにまとめて任せられ、しかも読み取り専用の権限で済みます。開発・ステージングのクラスターで、AmazonEKSMCPReadOnlyAccess だけを付けたロールから始めるのが現実的な入り方です。EKS Auto Modeでノード運用をAWSに任せているクラスターなら、AIに見せる範囲もワークロード側に絞れます。

一方、次の条件に当てはまるなら見送るか、読み取りに限定してください。

  • Argo CDやFluxでGitOps運用している：apply_yamlやmanage_k8s_resourceで直接変更すると、Gitとの差分（ドリフト）が生まれ、次の同期で巻き戻るか、逆に意図しない状態が固定されます。変更はプルリクエストで出す運用を崩さないことです。
  • プレビューの機能を本番運用に入れられない社内規程がある：ホスト型は「変更される可能性がある」と明記されたプレビューです。この場合はOSS版を読み取り専用で使います。
  • 本番クラスターがプライベートエンドポイントのみ：ホスト型からKubernetes APIへの書き込みは届きません。PodやDeploymentなどを直接変更する用途には使えません。

EKSそのものの構成や料金から確認したい場合は、Amazon EKSの仕組み・料金と採用判断を解説した記事が前提知識になります。

よくある質問

Amazon EKS MCP Serverの料金はかかりますか？

2026年10月2日時点で、EKSの料金ページ、ユーザーガイド、発表時のブログのいずれにも、EKS MCP Server自体の料金は書かれていません。ツールが呼び出す先のサービスには通常の料金がかかりますが、EKS MCP Server自体に追加料金があるかどうかは、記載が無いことだけでは判断できません。呼び出し先の例として、get_cloudwatch_logs はCloudWatch Logs Insightsのクエリを実行するので、スキャンしたデータ量に応じた通常のLogs Insights料金がかかります。manage_eks_stacksで作ったクラスターやNATゲートウェイも通常どおり課金されます。プレビュー終了時に条件が変わる可能性もあるため、GA発表の時点で料金ページを確認してください。

東京リージョン（ap-northeast-1）から使えますか？

使えます。発表時のAWSブログは、プレビューの提供範囲を「GovCloudと中国を除くすべての商用リージョン」としています。設定ではURLを https://eks-mcp.ap-northeast-1.api.aws/mcp、--region を ap-northeast-1 にします。2026年10月2日に署名なしでこのURLへ要求を送ると、HTTP 403（MissingAuthenticationTokenException）が返りました。署名が無いので拒否されただけで、エンドポイント自体は東京にあります。存在しないリージョン名に変えると名前解決の段階で失敗します。

AWS MCP ServerとEKS MCP Serverはどう使い分けますか？

EKSクラスターの中身（Pod、イベント、ログ、Insights）を扱うならEKS MCP Server、EKS以外も含めてAWSのAPIを広く呼びたいならAWS MCP Serverです。両方を同時に登録することもできます。その場合も、AWS MCP Serverにはクラスターの中を読む専用ツールが無いので、Podのログやイベントを読む役割はEKS MCP Serverに任せることになります。

OSS版からホスト型へ移行するときに変わる点は何ですか？

設定ファイルの awslabs.eks-mcp-server@latest を mcp-proxy-for-aws@latest とエンドポイントURLに差し替えます。そのうえで、OSS版のフラグに頼っていた権限をIAMの eks-mcp:* 系アクションへ移し、ツール名を直接書いた手順書を新しい名前に直します。

kubectlの代わりになりますか？

なりません。ツールは決められた操作の組み合わせで、port-forwardやexec、rollout undoに当たる専用のツールはありません。状態を読んで原因の当たりを付けるところまでをEKS MCP Serverに任せ、変更はkubectlかGitOpsで人が行う、という分担が安全です。Kubernetesのバージョンとサポート期限はKubernetesの最新バージョンと確認方法をまとめた記事で確認できます。

関連記事

お気に入りに入れた記事の一覧

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.10.09　テックブログ IDCFクラウドの不正アクセスとランサムウェア被害｜利用者の初動と別基盤への復旧手順
  2. 2026.10.08　テックブログ 大阪公立大学のランサムウェア被害と仮想化基盤の停止｜全授業休講に至った経緯とバックアップを守る設定
  3. 2024.11.08　テックブログ OpenAPI GeneratorでJavaコードを自動生成する方法｜CLI導入からSpring・ライブラリ選択まで
  4. 2026.10.09　テックブログ 京王電鉄のランサムウェア被害とグループ共通基盤：決済・ポイント・予約が止まった範囲と遮断の初動
  5. 2026.10.09　テックブログ ニッスイのサイバー攻撃で日水物流の入出荷停止｜委託先クラウド障害に荷主が備える手順

RELATED POSTS 関連記事

一覧へ戻る

目次