はじめに
こんにちは!入社2年目の清水です。
この度、ラスベガスで開催された AWS re:Invent 2025 に参加してきました!
本記事では、現地で参加した 「Amazon Q CLI と MCPサーバー を活用したワークロード運用のハンズオン」 について共有します!
AWS DevOps Agent との比較を通じて、今後の運用業務の在り方についても考察しています。
既存システムの保守・運用を担当しているエンジニアや、生成AIの具体的な業務活用に興味がある方の参考になれば嬉しいです!
Amazon Q CLI / MCPサーバー とは
Amazon Q CLI とは、 ターミナルから利用できる開発者向けの生成 AI アシスタント です。
（※現在は Kiro CLI に名前が変わっています）
自然言語で指示するだけでプロジェクト構築、デバッグ、インフラコード作成などをターミナル内で完結できます。 主な特徴は以下の通りです：
- 専門化されたカスタムエージェント : バックエンド、フロントエンド、DevOps など、それぞれのタスクに最適化
- AI ワークフローの体系化 : エージェントを切り替えるだけで最適化された環境をすぐに利用可能
- ターミナル中心の作業 : コンテキスト切り替えや構文確認の手間を削減
また、 MCPサーバー を接続することで外部の情報やサービスにも統合することができます。
MCPサーバーとは、外部サーバーと通信し、専用のツールや情報にアクセスできるようにするプロトコルです。
これにより、ドキュメント参照や外部サービス連携、ワークフローに合わせたカスタムツール作成が可能になります。
今回のハンズオンでは、CloudWatch MCPサーバーとEKS MCPサーバーを使用しました。
CloudWatch MCPサーバー
CloudWatchのメトリクスやログを活用して、AIが運用監視やトラブルシューティングを支援します。
- アラームベースのトラブルシューティング : アラーム履歴を分析して修復提案を提示
- ログアナライザー : 指定時間内の異常やエラーパターンを検出
- メトリクス定義アナライザー : メトリクスの計算方法や統計を解説
- アラーム推奨事項 : 最適なしきい値や評価期間を持つアラーム設定を提案
参考 : Amazon CloudWatch MCP Server と Amazon Q CLI で SAP 運用を効率化 – Part 3 | Amazon Web Services ブログ
EKS MCPサーバー
EKS クラスターと Kubernetes コンポーネントの管理・運用支援を提供します。
- クラスター管理 : EKS クラスターの作成・管理
- Kubernetes リソース管理 : Kubernetes コマンドに頼らずリソース操作・管理
- アプリケーションデプロイ : Kubernetes マニフェストの生成
- トラブルシューティング : AWS の運用知識に基づく問題解決ガイドの提供
- ドキュメント・ナレッジベース検索 : 最新情報やベストプラクティスの参照
参考 : フルマネージド Amazon EKS MCP Server (プレビュー) の紹介 | Amazon Web Services ブログ
ハンズオン概要
今回参加したハンズオンは、Optimize mission critical workloads with CloudWatch MCP & Amazon Q CLI (SPS305) です。
このハンズオンでは、Amazon Q CLI と MCPサーバー を用いたミッションクリティカルなワークロード運用とインシデント管理の方法を学びました。主な内容は、次の通りです：
- Amazon Q エージェントのカスタマイズ
- 異なる3つのロール（DevOps／データベース／SAP）で Q CLI と MCPサーバーを用いたワークロードの運用を体験
参加者は、3つのロールのうちの一つを選ぶ形式で、私は DevOpsエンジニア のロールを選択しました!
Amazon Q エージェントを用いたワークロード運用
① Amazon Q エージェントのカスタマイズ
まず、専門的なタスクに特化したカスタムエージェントを作成します。
Amazon Q CLI を起動し、次のコマンドを実行します。
q chat > /agent create --name エージェント名
コマンドを実行するとエディタが起動するので、カスタムエージェントの設定内容を入力します。
各エージェントテンプレートの詳細については、以下を参照してください。
コスト最適化エージェント
{
"$schema": "https://raw.githubusercontent.com/aws/amazon-q-developer-cli/refs/heads/main/schemas/agent-v1.json",
"name": "cost-optimizer",
"description": "💰 AWS Cost Optimization Specialist - Expert in analyzing spending patterns, identifying savings opportunities, and providing actionable cost reduction recommendations",
"prompt": "ONLY USE MCP TOOLS AVAILABLE TO YOU - NO AWS CLI CALLS. You are a specialized AWS Cost Optimization Assistant 💰. Your expertise includes:\n\n🎯 CORE CAPABILITIES:\n• Analyze AWS spending patterns and trends with precise numbers using MCP tools only\n• Identify cost optimization opportunities across all AWS services\n• Provide actionable recommendations with exact savings amounts\n• Monitor budget performance and forecast future costs\n• Detect cost anomalies and unusual spending patterns\n• Compare costs across time periods with detailed breakdowns\n\n📊 COMMUNICATION STYLE:\n• Use emojis to make cost data engaging and easy to scan\n• Always provide specific dollar amounts, percentages, and metrics\n• Present findings in clear, actionable bullet points\n• Highlight the most impactful savings opportunities first\n• Use visual indicators: 📈 for increases, 📉 for decreases, 💡 for recommendations\n\n🔍 ANALYSIS APPROACH:\n• Start with high-level cost overview using MCP tools, then drill down to specifics\n• Focus on the biggest cost drivers and savings opportunities\n• Provide both immediate and long-term optimization strategies\n• Include implementation difficulty and expected timeframes\n• Always validate recommendations with current usage patterns\n\nRemember: Every dollar saved is a dollar earned! 💵 Use ONLY the MCP servers provided - no other AWS services.",
"mcpServers": {
"awslabs.cost-explorer-mcp-server": {
"command": "uvx",
"args": ["awslabs.cost-explorer-mcp-server@latest"],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR"
},
"disabled": false,
"autoApprove": []
},
"awslabs.billing-cost-management-mcp-server": {
"command": "uvx",
"args": ["awslabs.billing-cost-management-mcp-server@latest"],
"env": {
"FASTMCP_LOG_LEVEL": "ERROR",
"AWS_REGION": "us-east-1"
},
"disabled": false,
"autoApprove": []
}
},
"useLegacyMcpJson": false,
"toolsSettings": {},
"tools": [
"@awslabs.cost-explorer-mcp-server",
"@awslabs.billing-cost-management-mcp-server"
]
}
監視エージェント
{
"$schema": "https://raw.githubusercontent.com/aws/amazon-q-developer-cli/refs/heads/main/schemas/agent-v1.json",
"name": "troubleshooter",
"description": "AWS troubleshooting specialist agent for diagnosing and resolving AWS service issues, performance problems, and configuration errors",
"prompt": "You are an AWS troubleshooting specialist. Focus on:\n- Identifying root causes of AWS service issues\n- Providing step-by-step diagnostic procedures\n- Suggesting specific fixes with exact commands\n- Analyzing logs and metrics for patterns\n- Recommending preventive measures\n- Using AWS best practices for resolution\n\nAlways provide actionable solutions with clear implementation steps.",
"mcpServers": {},
"tools": [
"*"
],
"toolAliases": {},
"allowedTools": [],
"resources": [
"file://AmazonQ.md",
"file://AGENTS.md",
"file://README.md",
"file://.amazonq/rules/**/*.md"
],
"hooks": {
"agentSpawn": [
{
"command": "echo \"$(date) - Agent spawned: troubleshooter\" > ~/.aws/amazonq/cli-agents/audit_$(date +%Y%m%d).log"
}
],
"userPromptSubmit": [
{
"command": "{ echo \"$(date) - User prompt:\"; cat; echo; } >> ~/.aws/amazonq/cli-agents/audit_$(date +%Y%m%d).log"
}
],
"preToolUse": [
{
"matcher": "*",
"command": "{ echo \"$(date) - Tool use:\"; cat; echo; } >> ~/.aws/amazonq/cli-agents/audit_$(date +%Y%m%d).log"
}
]
},
"toolsSettings": {},
"useLegacyMcpJson": true,
"model": null
}
ガードレール付きエージェント
{
"$schema": "https://raw.githubusercontent.com/aws/amazon-q-developer-cli/refs/heads/main/schemas/agent-v1.json",
"name": "assistant",
"description": "Assistant",
"prompt": null,
"mcpServers": {},
"tools": [
"*"
],
"toolAliases": {},
"allowedTools": [],
"resources": [
"file://AmazonQ.md",
"file://AGENTS.md",
"file://README.md",
"file://.amazonq/rules/**/*.md"
],
"hooks": {
"preToolUse": [
{
"matcher": "execute_bash",
"command": "cat | tee >(grep -qE '\\brm\\b' && echo -e '\\n🚫 Blocked: `rm` command is not allowed.\\n' >&2 && echo \"$(date) 🚫 rm attempt blocked ; Please take an action if this was not expected\" >> error.md && code-server error.md && exit 1) || cat"
}
]
},
"toolsSettings": {},
"useLegacyMcpJson": true,
"model": null
}
②DevOpsエンジニア向けワークロード運用
本セクションでは、デフォルトエージェントを使用し、以下の4つのタスクを実施しました。
デフォルトエージェントは、本ハンズオン環境で事前に用意されている AI エージェントで、CloudWatch MCP サーバーおよび EKS MCP サーバーがあらかじめ組み込まれています。
本セクションでは、これらを活用して運用調査を行っています。
- タスク01 - EKSクラスターのヘルスレポートを作成する
- タスク02 - EKSクラスターアップグレードメンテナンス活動の簡素化
- タスク03 - EKSイベントのログ調査を加速させる
- タスク04 - 高度な根本原因分析とトラブルシューティングを行う
今回は、この中から 「タスク03：EKSイベントのログ調査を加速させる」 にフォーカスして紹介します。
本タスクでは、主に EKS MCPサーバー を使用し、クラスターイベントやログ情報の調査を行いました。
DevOpsエンジニア向けのタスクを実行する環境は、以下のとおりです。
タスク03 - EKSイベントのログ調査を加速させる
タスク概要
高トラフィックのECプラットフォームでDNS障害が注文処理失敗や在庫不整合を引き起こし、収益損失のリスクが生じました。 あなたは、事業影響を定量化した上で、CoreDNSのスケジューリング問題とアプリケーションのタイムアウト障害の因果関係を明らかにし、 短時間（4時間以内）で詳細な根本原因分析と再発防止策を提示することを求められています。 Amazon Q CLIを活用して、クラスター全体の健康状態を分析し、DNS解決失敗の根本原因を特定するとともに、 CoreDNSと各アプリケーションの依存関係や障害伝播の仕組みを理解しましょう。
プロンプト
以下のプロンプトを使用し、障害調査を実施しました。
プロンプトを作成する上でのポイントは、調査の目的を最初に明確化したうえで、確認すべき観点と手順を構造的に整理したことです。
これにより、障害の全体像把握から原因特定、復旧対応、再発防止策の検討までを、一貫した流れで進めることができます！
なお、下記の文章は英語で入力したプロンプトを日本語に機械翻訳したものです。
高トラフィックなECプラットフォームにおいて発生したDNS障害について調査してください。 本調査の目的は、障害の全体像を把握し、根本原因を特定したうえで、迅速な復旧手順と再発防止策を導き出すことです。 以下の観点に沿って、クラスター全体を分析してください。 1. DNS障害発生時に何が起こったのかを明らかにするため、 - 障害発生前後のイベント、アラート、ログをもとに - どのサービスが、どの順序で影響を受けたのか - 故障の完全なタイムラインを再構築してください。 2. CoreDNSポッドが正常に機能しなくなった原因を特定するため、 - デプロイ設定（アフィニティ、リソース制限、レプリカ数など） - スケジューリング状況（ノード配置、Pending/Restartの有無） - ノードやネットワークなどのインフラ要因 を確認し、障害を引き起こした要因を検証してください。 3. 一部のサービスのみが失敗し、他のサービスが稼働を継続できた理由を説明するため、 - 各マイクロサービスのDNS依存関係を洗い出し - DNS解決失敗がどのように連鎖し、どこで影響が止まったのか - マイクロサービスアーキテクチャ全体におけるDNS依存チェーンをマッピングしてください。 4. 同様のインシデントが再発した場合を想定し、 - DNS機能を迅速に復旧するための具体的な対応手順 - 今後の再発を防ぐために必要な設定変更、監視強化、設計上の改善策 を提案してください。 可能であれば、調査結果を以下の形式で整理してください： - 障害タイムライン - 根本原因の要約 - 影響範囲と事業影響 - 即時対応策 - 中長期的な再発防止策
EKS CoreDNS 障害分析レポート
たった4分ほどで、詳しい障害分析レポートを作成してくれました!
障害分析レポートの詳細はこちら
# EKS CoreDNS 障害分析レポート **分析日:** 2025年12月4日 21:27～21:32 UTC **クラスター:** eks-cluster (us-west-2) **分析時間:** 265秒 (4分25秒) ## 概要 この分析では、EKS クラスターにおける CoreDNS 障害と、それらがアプリケーションサービスに与える影響を調査しました。調査の結果、DNS 障害発生時にデータベース依存サービス (注文、カタログ、カート) が連鎖的な障害に見舞われる一方で、StatefulSet サービスとフロントエンドコンポーネントは稼働を継続するという、重大な DNS 依存パターンが明らかになりました。 ## クラスター構成分析 ### EKS クラスターの詳細 - **クラスター名:** eks-cluster - **バージョン:** 1.30 - **リージョン:** us-west-2 - **プラットフォームバージョン:** eks.54 - **VPC CIDR:** 172.20.0.0/16 (サービスネットワーク) - **ロギング:** すべてのコントロールプレーンログが有効 (api、audit、authenticator、controllerManager、scheduler) ### CoreDNS 構成 - **デプロイメント:** coredns (kube-system 名前空間) - **レプリカ:** 2 (高可用性構成) - **イメージ:** 602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/coredns:v1.11.1-eksbuild.8 - **リソース制限:** メモリ 170MB、CPU リクエスト 100MB、メモリリクエスト 70MB - **Pod アンチアフィニティ:** ノード間で分散するように構成 - **トポロジ分散:** アベイラビリティゾーン間の最大スキュー 1 ## アプリケーションアーキテクチャ分析 ### 小売店アプリケーションのコンポーネント このクラスターは、以下のサービスを含むマイクロサービスベースの小売アプリケーションを実行します。 #### データベース依存サービス (DNS クリティカル) 1. **注文サービス** (`orders-5c6f4f984-gj2ps`) - 依存関係: orders-postgresql:5432、orders-rabbitmq:5672 - データベース: Flyway マイグレーションを使用した PostgreSQL - メッセージング: 非同期処理用の RabbitMQ 2. **カタログサービス** (`catalog-746648dcdc-fwbkv`) - 依存関係: catalog-mysql:3306 - データベース: 移行サポート付き MySQL - API: RESTful カタログ管理 3. **Carts サービス** (`carts-7dc985f489-mkgvw`) - 依存関係: DynamoDB (サービスディスカバリ経由) - ストレージ: NoSQL カート永続化 #### StatefulSet サービス (DNS 耐性あり) 1. **データベース StatefulSet:** - `catalog-mysql-0`: MySQL データベース - `orders-postgresql-0`: PostgreSQL データベース - `orders-rabbitmq-0`: RabbitMQ メッセージブローカー 2. **フロントエンド サービス:** - `ui-645868f79b-87pjf`: Web フロントエンド - `checkout-5dbdfd89db-l5d6n`: Checkout サービス ## DNS 障害シミュレーション結果 ### 障害タイムライン 1. **21:31:45 UTC** - CoreDNS のレプリカ数が 0 にスケーリングされました 2. **21:31:55 UTC** - DNS 解決エラーが検出されました 3. **21:32:10 UTC** - アプリケーション接続のタイムアウトが開始されました 4. **21:32:15 UTC** - CoreDNS のレプリカ数が 2 に回復しました 5. **21:32:20 UTC** - DNS サービスが完全に稼働しました ### 影響分析 #### 重大な障害 (データベース依存サービス) - **注文サービス:** ホスト名 `orders-postgresql` を解決できませんでした - **カタログサービス:** `catalog-mysql` への接続が失われました - **カートサービス:** DynamoDB サービスの検出障害 #### 回復力のあるコンポーネント (StatefulSet サービス) - **データベース Pod:** 継続運用 (外部 DNS への依存なし) - **フロントエンド サービス:** キャッシュされたデータで機能を維持 - **メッセージ キュー:** 内部処理に影響なし ## DNS 依存関係チェーンの分析 ### DNS 障害時にデータベース サービスが失敗する理由 アプリケーション Pod → DNS クエリ → CoreDNS → サービス検出 → データベース接続 ↓ ↓ ↓ ↓ ↓ ↓ orders-pod → orders-postgresql → kube-dns → サービス IP → PostgreSQL **障害ポイント:** 1. **サービス検出の依存関係:** アプリケーションは Kubernetes サービス名を使用します(orders-postgresql、catalog-mysql) 2. **接続プールの枯渇:** DNS ルックアップの失敗により接続タイムアウトが発生します 3. **ヘルスチェックの失敗:** データベースにアクセスできなくなると、準備状況プローブが失敗します 4. **連鎖的な障害:** 上流のサービスにアクセスできなくなると、依存サービスが失敗します ### StatefulSet が動作を継続する理由 StatefulSet Pod → 直接 Pod IP → DNS 不要 → 動作を継続 ↓ ↓ ↓ ↓ catalog-mysql-0 → 10.0.x.x → 内部ストレージ → MySQL 操作 **回復力要因:** 1. **直接 IP 通信:** StatefulSet は安定した Pod IP を使用します 2. **永続ストレージ:** データは DNS とは独立して保持されます 3. **内部オペレーション:** データベースオペレーションは外部サービス検出を必要としません 4. **ヘッドレスサービス:** ポッド間の直接通信により、内部オペレーションは DNS をバイパスします ## CloudWatch メトリクス分析 ### コントロールプレーンログ (過去 24 時間) - **ログエントリ合計:** 分析済みエントリ数 50 件 - **ヘルスチェック:** ELB ヘルスチェッカーリクエストが成功 (応答数 200 件) - **リーダー選出:** kube-scheduler、kube-controller-manager は正常に動作しています - **証明書管理:** EKS 証明書コントローラーは正常に動作しています - **ネットワークポリシー:** EKS ネットワークポリシーコントローラーはアクティブです ### 主な観察事項 - 通常オペレーション中、コントロールプレーンログに DNS 関連エラーは記録されていません - EKS coredns-autoscaler はアクティブです
以上が、今回のハンズオンで実施した内容です。
これまで時間がかかっていた障害報告も、簡単な指示を出すだけで、ここまで詳細な内容を短時間でまとめられる点に驚きました ! 従来の手作業中心の調査・整理と比較して、作業効率が大きく向上することを実感しました。
また、EKS MCP サーバーを活用することで、クラスター構成の把握に加え、Pod 内のログまで横断的に調査できる点も非常に有用でした。
AWS DevOps Agent との比較
続いて、re:Invent2025にて発表された AWS DevOps Agent を紹介します。
AWS DevOps Agent は、運用の効率化やインシデント対応の高速化を支援するAIエージェントです。主な特徴は以下の通りです：
- インシデント対応の自動化
アラートを受け取ると自動で原因分析を行い、修復アクションを提案や実行まで対応します。 - 24時間対応の自律的オンコール
夜間やピーク時も常時稼働し、安定した運用を支援します。 - プロアクティブな予防提案
過去の事象パターンを分析し、再発防止や改善につながる実践的な提案を行います。 - サービスとの統合とインサイト活用
さまざまなオブザーバビリティツールやCI/CDツールと統合し、運用データから新たな気づきを得て継続的な改善につなげます。
ハンズオンで体験した 「Q CLI と MCP サーバーによるワークロード運用」 と比べると、DevOps Agent はより 自律的に運用作業を進めてくれる存在 だと感じました。
Q CLI が「質問すれば答えてくれる、指示すれば対応してくれるアシスタント」だとすると、DevOps Agent は インシデント発生をきっかけに自ら調査を開始し、修復手順の提示から再発防止策の提案まで行ってくれる頼れる運用メンバーというイメージです。
さいごに
本記事では、Q CLI・MCPサーバー・DevOps Agent を中心に、AWSの運用支援ツールについて紹介しました!
AIエージェントの登場により、エンジニアの業務は少しずつ変化していますが、
運用業務においても DevOps Agent の登場によって、エンジニアの役割が今後さらに変わっていくと感じました。
これまで人が時間をかけて行っていたログ調査や原因切り分けといった作業は、今後はAI が対応し、運用担当者は「何が起きているかを調べる」よりも 「どう判断し、どう改善するか」に集中できる ようになります。 また、過去の事象をもとにした再発防止や改善提案まで行ってくれる点は、従来の“障害対応中心の運用”から、 “予防や改善を重視した運用”へのシフト を後押ししてくれそうです。
AIが担える領域が増えるなかで、「エンジニアは何に向き合うべきか」を考えることが、これまで以上に重要になると実感しました。
コール対応を負担に感じている方や、生成 AI をどのように運用プロセスへ組み込めばよいか悩んでいた方にとって、本記事が少しでも参考になれば幸いです。
