
【レポート】 CloudWatch MCP と Amazon Q CLI で運用を変革するワークショップ「Optimize mission critical workloads with CloudWatch MCP & Amazon Q CLI」に参加しました!#AWSreInvent #SPS305
こんにちは!クラウド事業本部のおつまみです。
今回はre:Invent2025のセッション 「Optimize mission critical workloads with CloudWatch MCP & Amazon Q CLI」 に参加してきたので、内容をご紹介します!
セッションの概要
タイトル
Optimize mission critical workloads with CloudWatch MCP & Amazon Q CLI
概要
Amazon CloudWatch (CW) Model Context Protocol (MCP) server and Amazon Q CLI transforms mission critical workload operations and incident management.Simplify maintenance by providing integrated observability and natural language command generation, turning complex procedures into simple tasks. Convert automated routine operations through Q CLI's ability to translate conversational requests into precise AWS commands, eliminating repetitive work. Accelerate root-cause analysis and reduce resolution times by delivering contextual monitoring data directly within client environments, while Q CLI enables rapid remediation through conversational troubleshooting commands for mission critical workloads and AWS infrastructure issues.
Amazon CloudWatch (CW) Model Context Protocol (MCP) サーバーと Amazon Q CLI は、ミッションクリティカルなワークロード運用とインシデント管理を変革します。統合された可観測性と自然言語コマンド生成を提供することでメンテナンスを簡素化し、複雑な手順をシンプルなタスクに変えます。Q CLI は会話型リクエストを正確な AWS コマンドに変換するため、自動化された定型操作を変換し、反復作業を排除します。また、コンテキストに基づいたモニタリングデータをクライアント環境に直接提供することで、根本原因分析を加速し、解決時間を短縮します。さらに、Q CLI は会話型のトラブルシューティングコマンドを通じて、ミッションクリティカルなワークロードや AWS インフラストラクチャの問題を迅速に修復できます。
スピーカー
- Wael Dimassi, Technical Account Manager, Amazon Web Services
- Vijay Sitaram, Principal TAM, AWS
レベル
300
Session Type
Workshop
ワークショップ前の説明
本ワークショップの最重要テーマは「シンプリシティ」ということで以下3点を大事にしているようでした

- Amazon Q CLI の力と MCP サーバーを活用して時間を節約
- 複雑なタスクを自動化してコストを削減
- 単純作業から解放され、イノベーションに集中できる時間を創出
Amazon Q CLI の特徴
Amazon Q CLI は、エンタープライズ向けのコマンドラインツールです(今はKiro CLIに変わってます)

- 生成AI機能を統合 - 複雑なCLIコマンドを覚える必要がない
- 自然言語で操作 - Linux コマンドや AWS サービスのコマンドを知らなくても、英語で質問するだけで実行可能
- 開発者だけでなく、DevOps エンジニアやマネージャーも使用可能
- インフラストラクチャの管理とトラブルシューティングを簡素化
使用する MCP サーバー
1. CloudWatch MCP サーバー

- AWS Labs が開発したオープンソースコンポーネント
- CloudWatch の機能を拡張
- コンテキストに基づいたモニタリングデータ交換のプロトコルを提供
- CloudWatch とターミナル間のブリッジとして機能
- 構造化された方法でモニタリングデータを整理し、可観測性を向上
2. EKS MCP サーバー

- AI 駆動の自然言語リクエストで EKS 環境を強化
- EKS の知識がなくても、シンプルな英語で質問可能
- 推論を通じて目標を理解し、必要なデータを判断
- EKS クラスターを理解し、kubectl を使用して情報を取得
- リクエストを満たすための最適な方法を自動的に決定
- 運用を効率化し、複雑さを軽減
実践的な導入メリット
1. 平均解決時間(MTTR)の短縮
- GenAI ツールは複雑なシステム状態を分析し、修復手順を提案
- CloudWatch MCP はインシデント発生時にコンテキストに基づいた洞察を提供
2. プロアクティブな運用
- パターン認識による反応型から予測型オペレーションへの移行
- 微妙な異常検出に基づく早期警報システム
3. 知識の民主化
- Amazon Q CLI を使用することで、チームメンバーは自然言語で複雑なシステムを操作可能
- 日常業務における専門知識への依存を軽減
4. 継続的な改善
- GenAI による運用パターンの分析によるアーキテクチャの改善提案
- コンテキストに応じた推奨事項を備えた自動化された Well-Architected レビュー
5. 合理化されたコンプライアンス
- 自動化されたポリシー検証とコンプライアンスチェック
- 監査と報告のための自然言語インターフェース
ワークショップ概要
まずAmazon Q エージェントのカスタマイズを実施します。
その後3つの異なるロール(DevOps、→ データベース → ERP)毎のワークロードが用意してある環境で CloudWatch MCP と Amazon Q CLI を活用し、ヘルスレポートを作成します。どれか1つのロールを選択する感じでした。
1. EKS クラスターの DevOps エンジニア
EKS のトラブルシューティングを手動 CLI から直感的な会話へと移行し、MTTR を短縮し、効率性を向上させる。CloudWatch MCP と連携した Q CLI により、自然言語クエリを使用して EKS クラスターのトラブルシューティングを行い、複雑な kubectl コマンドやコンソールナビゲーションを必要とせずに、ログ、メトリクス、アラームに即座にアクセスする。

2. Aurora MySQL クラスターのデータベース管理者
Aurora のトラブルシューティングを手動の SQL とコンソール操作から直感的な会話へと移行することで、MTTR を短縮し、データベースの効率性を向上させる。CloudWatch MCP と Q CLI を組み合わせることで、自然言語クエリを使用して Aurora MySQL クラスターのトラブルシューティングを実行でき、複雑な SQL コマンドやコンソール操作を必要とせず、パフォーマンスメトリクス、スロークエリログ、アラームに即座にアクセスできる。

3. SAP アプリケーション用の Unix および SAP 管理者
高可用性 (HA) 展開を備えた Pacemaker クラスタで展開された SAP アプリケーションの管理において、SAP BASIS と AWS の管理を手動コマンドから直感的な会話へと変革し、MTTR を短縮し、システム効率を向上させる。CloudWatch MCP と連携した Q CLI により、自然言語クエリを使用して SAP システムと AWS インフラストラクチャのトラブルシューティングを行い、複雑な SAP コマンドやコンソールナビゲーションを使用せずに、HANA メトリクス、SAP アプリケーションログ、EC2 アラームに即座にアクセスできる。

EKSはやってみたブログがあったので、今回は1番利用しそうなAurora MySQL クラスターのシナリオを途中までやってみました。
1. Amazon Q エージェントのカスタマイズ
その前にミッションクリティカルなワークロード向けの Amazon Q エージェントを作成します。
デフォルトエージェントではなく、特定のロール、セキュリティ要件、運用ニーズに合わせてカスタマイズされた AI アシスタントを/agentコマンドで作成できます。
今回は以下3つのエージェントを事前に作成しました。
- 限定エージェント - cost-optimizer
- 監視対象エージェント - troubleshooter
- ガードレール付きエージェント - assistant
1. 限定エージェント - cost-optimizer
特定のユースケース向けにツールアクセスが制限された専用エージェント
主なスキル:
- 特定の MCP サーバーアクセスのみを持つエージェントを構成
- ツールの制限がエージェントの行動にどのように影響するかを理解
- コスト最適化チーム向けに役割別のエージェントを作成
- エージェントが自分の範囲外のリクエストをリダイレクトする方法を体験
qコマンドでKiroを呼び出し、/agent create -n cost-optimizerを実行した後にテンプレートを設定します。
cost-optimizer エージェントのテンプレート
{
"$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"
]
}
このエージェントでエージェントのスコープ外のリクエストEC2 AMIの一覧を取得してを投げると、以下のように私はリソース一覧は取得できませんとできることが制限されていることが確認できます。これはコスト関連の MCP サーバーにのみアクセスできるように設定しているためです。
出力結果
オレゴンの EC2 AMI を一覧表示したいとのことですが、AWS コスト最適化アシスタント 💰 として、AMI やその他のインフラストラクチャ リソースを一覧表示するツールがありません。
私の専門分野は、以下の機能を使用したコスト分析と最適化です。
🔧利用可能なコストツール:
コストと使用状況の分析 📊
予算の監視💵
コスト最適化の推奨事項 💡
Savings Plansとリザーブドインスタンスの分析 📈
コスト予測 🔮
AMI をリストするには、AWS CLI を使用する必要があります。
1. aws ec2 describe-images --owners self --region us-west-2
EC2 コストの最適化をお手伝いできます!💰 以下のことをご希望ですか?
オレゴンでの現在の EC2 支出を分析しますか? 📊
適正規模の機会をお探しですか?💡
地域間でコストを比較しますか? 🌎
未使用または十分に活用されていないインスタンスを特定しますか? 🔍
代わりに、あなたのお金を節約することに集中させてください!💵
2. 監視対象エージェント - troubleshooter
同様な手順で/agent create -n troubleshooterを実行した後に以下のテンプレートを設定します。
troubleshooter エージェントのテンプレート
{
"$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
}
このエージェントで先ほどのリクエストEC2 AMIの一覧を取得してを投げると、tail -f audit_*.logを別のターミナルで実行すると、監査ファイルに実行のリアルタイムログが表示されます。
ubuntu@dev:/q-cli-troubleshooting-demo$ cd ~/.aws/amazonq/cli-agents/
ubuntu@dev:~/.aws/amazonq/cli-agents$ tail -f audit_*.log
Thu Dec 4 20:32:08 UTC 2025 - Agent spawned: troubleshooter
Thu Dec 4 20:33:02 UTC 2025 - User prompt:
{"hook_event_name":"userPromptSubmit","cwd":"/home/ubuntu/.aws/amazonq/cli-agents","prompt":"list my ec2 instances ami in oregon region"}
Thu Dec 4 20:33:06 UTC 2025 - Tool use:
{"hook_event_name":"preToolUse","cwd":"/home/ubuntu/.aws/amazonq/cli-agents","tool_name":"use_aws","tool_input":{"service_name":"ec2","operation_name":"describe_instances","region":"us-west-2","label":"List EC2 instances with AMI in Oregon region","parameters":{}}}
3. ガードレール付きエージェント - アシスタント
同様な手順で/agent create -n assistantを実行した後に以下のテンプレートを設定します。
assistant エージェントのテンプレート
{
"$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
}
このエージェントでcreate a file then delete itを投げると、エージェントがファイルを削除しようとしたときにガードレールがアクティブになります。このようにデータ損失の防止やネットワークアクセスの制限をかけられます。

データベースエンジニア向けワークショップ
4つのタスクを以下の環境で実行するといった内容でした。

- タスク 01: RDS クラスターのヘルスレポートを作成する
- タスク 02: 計画されたメンテナンスアクティビティを作成する
- タスク 03: ログを調査し、データベースクラスターの障害とフェイルオーバーイベントをトラブルシューティングする
- タスク 04: Amazon Q を使用して Lambda 関数をテストし、トラブルシューティングする
タスク 01 の詳細: RDS クラスターのヘルスレポート作成
以下のプロンプトを実行し、レポートを作成してもらいました。
RDSクラスターの健全性評価について、包括的かつ詳細なチェックを実施してください。以下を含めること:
- **エグゼクティブサマリー**
- **詳細なインフラストラクチャ健全性評価**
- EC2ノード
- EBSボリューム
- VPCネットワーキング
- セキュリティグループ
- IAMロール
- コスト分析
- **CloudWatch Container Insightsメトリクス**の調査
- **アプリケーションログ**の調査
- **クラスターイベント**の調査
- **Pod再起動パターン**の調査
- **セキュリティ標準**に基づくクラスターセキュリティ態勢の評価
- **最近の問題と解決策**を含む
- **最適化、スケーリング、セキュリティ改善のための推奨事項**
- **結論**
また、以下もリストアップすること:
- このプロンプトで呼び出されたAWSサービスAPI
- kubectlコマンド
- MCPサーバー
- このプロンプトの処理にかかった時間
- 人間が同じタスクを実行する場合と比較して節約された時間
こちらを実行すると10分ほどで以下の結果が出力されました。
出力結果
RDS クラスター包括的分析レポート
エグゼクティブサマリー
**レポート日時**: 2025年12月4日
**対象クラスター**: riv-2025-305-rds (Aurora MySQL 8.0)
**リージョン**: us-west-2 (オレゴン)
**分析期間**: 2025年11月27日 - 2025年12月4日 (7日間)
---
📊 総合評価
| カテゴリ | スコア | ステータス |
|---------|--------|-----------|
| **パフォーマンス** | 85/100 | ✅ 良好 |
| **セキュリティ** | 45/100 | 🔴 要改善 |
| **コスト効率** | 40/100 | 🔴 要改善 |
| **可用性** | 90/100 | ✅ 優秀 |
| **コンプライアンス** | 35/100 | 🔴 要改善 |
**総合スコア: 59/100** - 即座の改善が必要
---
🎯 主要な発見事項
### ✅ 強み
1. **高可用性構成**: Multi-AZ 配置で99.95%の可用性を実現
2. **優秀なパフォーマンス**: CPU使用率6-7%、レイテンシ0.4ms以下
3. **暗号化実装**: ストレージとスナップショットの暗号化が有効
4. **ネットワーク隔離**: プライベートサブネットに適切に配置
### 🔴 重大な問題
1. **未使用リソース**: データベース接続が0、実質的に未稼働
2. **セキュリティギャップ**: 監査ログ無効、削除保護なし
3. **コスト非効率**: 月額約$400のリソースが未活用
4. **コンプライアンス違反**: バックアップ保持期間1日のみ
---
💰 財務インパクト
### 現在の月額コスト (推定)
- **DB インスタンス (2台)**: db.r7g.large × 2 = $364/月
- **ストレージ**: 1GB (最小) = $0.10/月
- **バックアップストレージ**: ~1GB = $0.02/月
- **データ転送**: 最小 = $0/月
- **拡張モニタリング**: 60秒間隔 × 2 = $7.20/月
**合計月額コスト: 約$371/月 ($4,452/年)**
### 💡 コスト最適化の機会
1. **即座の削減**: インスタンス停止で $364/月削減 (未使用のため)
2. **インスタンスサイズ変更**: db.r7g.medium に変更で $182/月削減
3. **リザーブドインスタンス**: 1年前払いで30%削減 ($1,335/年節約)
4. **Savings Plans**: 3年契約で50%削減 ($2,226/年節約)
**潜在的な年間節約額: $2,226 - $4,368**
---
🏗️ インフラストラクチャ概要
### クラスター構成
- **クラスター名**: riv-2025-305-rds
- **エンジン**: Aurora MySQL 8.0.mysql_aurora.3.08.2
- **作成日**: 2025年12月2日
- **稼働日数**: 3日
### インスタンス構成
#### インスタンス 1 (リーダー)
- **ID**: riv-2025-305-rds-instance-1
- **タイプ**: db.r7g.large (2 vCPU, 16 GiB RAM)
- **AZ**: us-west-2a
- **ロール**: リーダー
- **ステータス**: available
#### インスタンス 2 (ライター)
- **ID**: riv-2025-305-rds-instance-2
- **タイプ**: db.r7g.large (2 vCPU, 16 GiB RAM)
- **AZ**: us-west-2b
- **ロール**: ライター
- **ステータス**: available
### ネットワーク構成
- **VPC**: vpc-0e0aabfd9581cd0a6
- **サブネット**:
- subnet-04cfc817ff8d1910b (us-west-2a, 10.0.1.0/24)
- subnet-0c47152a0ec2aaadd (us-west-2b, 10.0.2.0/24)
- **セキュリティグループ**: sg-0722c1194ed32318a
- **パブリックアクセス**: 無効 ✅
- **エンドポイント**:
- ライター: riv-2025-305-rds.cluster-cjcgi22cqovg.us-west-2.rds.amazonaws.com
- リーダー: riv-2025-305-rds.cluster-ro-cjcgi22cqovg.us-west-2.rds.amazonaws.com
### 関連リソース
- **KMS キー**: ac5e39db-5b1b-43b8-9324-2e5ee04f206d (AWS マネージド)
- **IAM ロール**: rds-monitoring-role (拡張モニタリング用)
- **パラメータグループ**: default.aurora-mysql8.0
- **オプショングループ**: default:aurora-mysql-8-0
---
📈 パフォーマンス分析 (過去7日間)
### CPU 使用率
- **平均**: 6.4-7.0% (非常に低い)
- **最大**: 39.7% (2025-12-02 11:52 UTC - 起動直後のみ)
- **通常時最大**: 8-9%
- **評価**: ✅ **優秀** - CPU リソースに大幅な余裕
**主要な観察事項**:
- 12月2日の起動直後に一時的に39.7%まで上昇 (初期化処理)
- 12月4日 16:52 に18%の小さなスパイク (通常の変動範囲内)
- それ以外は一貫して6-9%の低い使用率を維持
- **結論**: 現在のワークロードに対してオーバープロビジョニング
### メモリ使用状況
- **利用可能メモリ**: 約6.2-6.7 GB
- **使用メモリ**: 約9-10 GB (総容量16GB)
- **使用率**: 約56-63%
- **トレンド**: 緩やかに減少中 (約140MB/日)
- **評価**: ✅ **正常** - メモリリークの兆候なし
**主要な観察事項**:
- メモリ使用量は安定しており、異常な増加なし
- バッファプールとキャッシュが適切に機能
- 現在のワークロードに対して十分な余裕
### レイテンシ分析
#### 書き込みレイテンシ
- **範囲**: 0.37-0.46 ミリ秒
- **平均**: 約0.42 ミリ秒
- **評価**: ✅ **優秀** - Aurora の標準的な性能
**トレンド**:
- 12月2日: 0.37-0.39ms (最良)
- 12月3日以降: 0.44-0.46ms (わずかに増加)
- 増加は正常範囲内で、ストレージの断片化によるもの
#### 読み取りレイテンシ
- **12月2日**: 0.07-0.17 ミリ秒
- **12月3日 12:00以降**: ほぼ0 (読み取りクエリなし)
- **評価**: ✅ **正常** - 読み取り負荷が非常に低い
**主要な観察事項**:
- 12月3日正午以降、読み取りアクティビティがほぼ停止
- アプリケーションの停止またはメンテナンス中の可能性
### データベース接続
- **接続数**: 0 (全期間)
- **評価**: 🔴 **重大な問題**
**影響**:
- アプリケーションからの接続が確立されていない
- クラスターが実質的に未使用
- 月額$371のコストが無駄になっている可能性
### デッドロックとエラー
- **デッドロック発生数**: 0 (全期間)
- **評価**: ✅ **優秀**
### パフォーマンスボトルネック
#### 検出された問題
1. **データベース接続が0**
- 過去7日間、アクティブな接続が記録されていない
- クラスターが使用されていないか、メトリクスの収集に問題がある可能性
2. **読み取りアクティビティの停止**
- 12月3日 12:00以降、読み取りクエリがほぼ実行されていない
- アプリケーションの停止またはメンテナンス中の可能性
#### 検出されなかった問題
- ✅ CPU スパイクなし
- ✅ メモリリークなし
- ✅ レイテンシの異常なし
- ✅ デッドロックなし
- ✅ ストレージの問題なし
### パフォーマンス推奨事項
1. **即座に確認すべき項目**:
- アプリケーションが RDS に接続しているか確認
- データベース接続文字列の検証
- セキュリティグループのルールを再確認
2. **監視の改善**:
- CloudWatch ログを有効化 (エラーログ、スロークエリログ、監査ログ)
- Performance Insights の有効化を検討
- カスタムメトリクスアラームの設定
3. **リソース最適化**:
- 現在のワークロードに対してインスタンスサイズが過剰
- db.r7g.medium への変更を検討 (月額$182削減)
- または、ワークロードが増加するまでクラスターを停止
---
🔒 セキュリティ分析
### セキュリティスコア: 45/100
### 🔴 重大な脆弱性 (Critical)
#### 1. ネットワークの完全な隔離
- **問題**: VPC にインターネットゲートウェイや NAT ゲートウェイが存在しない
- **影響**:
- パッチ適用やソフトウェア更新ができない
- AWS サービスへの接続に VPC エンドポイントが必要だが未設定
- 外部からの管理アクセスが不可能
- **リスクレベル**: 🔴 Critical
- **CVSS スコア**: 7.5 (High)
#### 2. バックアップ保持期間が最小値
- **現在の設定**: 1日
- **問題**: ランサムウェア攻撃や誤削除からの復旧が困難
- **コンプライアンス違反**:
- PCI-DSS 要件 3.1
- HIPAA §164.308(a)(7)
- SOC 2 A1.2
- **リスクレベル**: 🔴 Critical
- **推奨**: 最低7日、本番環境では30日以上
#### 3. 削除保護が無効
- **現在の設定**: DeletionProtection = false
- **問題**: 誤操作や悪意のある削除が可能
- **リスクレベル**: 🔴 Critical
- **推奨**: 即座に有効化
### 🟠 高リスクの脆弱性 (High)
#### 4. IAM データベース認証が無効
- **現在の設定**: IAMDatabaseAuthenticationEnabled = false
- **問題**:
- データベースパスワードがハードコードされるリスク
- 認証情報のローテーションが困難
- 監査証跡が不十分
- **リスクレベル**: 🟠 High
#### 5. Performance Insights が無効
- **問題**:
- セキュリティインシデント時の調査が困難
- 異常なクエリパターンの検出不可
- **リスクレベル**: 🟠 High
#### 6. CloudWatch ログが無効
- **無効なログ**: エラーログ、監査ログ、スロークエリログ、一般ログ
- **問題**:
- セキュリティイベントの追跡不可
- コンプライアンス監査に必要なログがない
- 不正アクセスの検出が困難
- **コンプライアンス違反**:
- PCI-DSS 要件 10.2
- HIPAA §164.312(b)
- SOC 2 CC7.2
- **リスクレベル**: 🟠 High
#### 7. スナップショットのタグ付けが無効
- **現在の設定**: CopyTagsToSnapshot = false
- **問題**: バックアップの管理と追跡が困難
- **リスクレベル**: 🟠 High
### 🟡 中リスクの脆弱性 (Medium)
#### 8. セキュリティグループが自己参照のみ
- **現在の設定**: インバウンドルールが sg-0722c1194ed32318a からのみ
- **問題**:
- アプリケーションサーバーからの接続が設定されていない
- 実際の接続元が不明確
- **リスクレベル**: 🟡 Medium
#### 9. AWS マネージド KMS キーを使用
- **現在の設定**: デフォルトの AWS マネージドキー
- **問題**:
- キーのローテーションポリシーを制御できない
- キーへのアクセス制御が限定的
- クロスアカウントアクセスが不可
- **リスクレベル**: 🟡 Medium
- **推奨**: カスタマーマネージド KMS キーへの移行
#### 10. Activity Stream が無効
- **現在の設定**: ActivityStreamStatus = stopped
- **問題**: データベースアクティビティの監査証跡がない
- **リスクレベル**: 🟡 Medium
### ✅ 適切に設定されている項目
1. **暗号化**: ストレージ暗号化が有効 (StorageEncrypted = true)
2. **スナップショット暗号化**: 自動スナップショットも暗号化
3. **パブリックアクセス**: PubliclyAccessible = false
4. **Multi-AZ**: 高可用性構成
5. **拡張モニタリング**: 60秒間隔で有効
6. **プライベートサブネット**: RDS がプライベートサブネットに配置
7. **IAM ロール**: モニタリングロールが適切に設定
### コンプライアンスギャップ
#### PCI-DSS
- ❌ バックアップ保持期間不足 (要件 3.1)
- ❌ 監査ログ無効 (要件 10.2)
- ❌ 削除保護無効 (要件 3.4)
- **コンプライアンススコア**: 40/100
#### HIPAA
- ❌ 監査証跡不足 (§164.312(b))
- ❌ バックアップ保持期間不足 (§164.308(a)(7))
- ⚠️ カスタマーマネージド KMS キー推奨 (§164.312(a)(2))
- **コンプライアンススコア**: 35/100
#### SOC 2
- ❌ ログ記録不足 (CC7.2)
- ❌ バックアップ保持期間不足 (A1.2)
- ❌ 削除保護無効 (CC6.1)
- **コンプライアンススコア**: 30/100
#### GDPR
- ⚠️ データ保護影響評価 (DPIA) の証跡不足
- ⚠️ データ削除手順の文書化が必要
- **コンプライアンススコア**: 50/100
---
💰 コスト最適化の詳細分析
### 現在のコスト内訳
#### 月額コスト (オンデマンド料金)
| リソース | 数量 | 単価 | 月額コスト |
|---------|------|------|-----------|
| db.r7g.large インスタンス | 2 | $0.252/時間 | $364.32 |
| ストレージ (Aurora) | 1 GB | $0.10/GB | $0.10 |
| バックアップストレージ | 1 GB | $0.021/GB | $0.02 |
| 拡張モニタリング | 2インスタンス | $3.60/月 | $7.20 |
| データ転送 | 最小 | - | $0.00 |
| **合計** | - | - | **$371.64/月** |
**年間コスト**: $4,459.68
### コスト最適化の機会
#### オプション 1: 即座の停止 (未使用のため)
- **削減額**: $364.32/月 ($4,371.84/年)
- **残存コスト**: $7.32/月 (ストレージとバックアップのみ)
- **節約率**: 98%
- **推奨**: データベース接続が0のため、使用開始まで停止を検討
#### オプション 2: インスタンスサイズの変更
- **変更**: db.r7g.large → db.r7g.medium
- **新しいコスト**: $182.16/月 (インスタンス)
- **削減額**: $182.16/月 ($2,185.92/年)
- **節約率**: 50% (インスタンスコスト)
- **推奨**: 現在のCPU使用率6-7%を考慮すると適切
#### オプション 3: リザーブドインスタンス (1年契約)
- **前払い**: 全額前払い
- **割引率**: 約30%
- **年間コスト**: $3,124 (通常$4,460)
- **削減額**: $1,336/年
- **推奨**: ワークロードが確定してから検討
#### オプション 4: Savings Plans (3年契約)
- **前払い**: 全額前払い
- **割引率**: 約50%
- **年間コスト**: $2,230 (通常$4,460)
- **削減額**: $2,230/年
- **推奨**: 長期的な使用が確定している場合
#### オプション 5: Aurora Serverless v2 への移行
- **最小ACU**: 0.5 (約$0.12/時間)
- **最大ACU**: 2 (約$0.48/時間)
- **推定月額**: $43.20 - $172.80 (使用パターンによる)
- **削減額**: $198.84 - $328.44/月
- **節約率**: 53-88%
- **推奨**: 断続的なワークロードに最適
### 推奨されるコスト最適化戦略
#### 短期 (1-2週間)
1. **ワークロードの確認**: データベース接続が0の原因を特定
2. **未使用の場合**: クラスターを停止し、月額$364削減
3. **使用予定の場合**: インスタンスサイズを db.r7g.medium に変更
#### 中期 (1-3ヶ月)
1. **ワークロードパターンの分析**: 実際の使用状況を監視
2. **Aurora Serverless v2 の評価**: 断続的なワークロードの場合
3. **リザーブドインスタンスの検討**: 継続的な使用が確定した場合
#### 長期 (3-12ヶ月)
1. **Savings Plans の購入**: 3年契約で50%削減
2. **マルチリージョン戦略**: 必要に応じてグローバルデータベースを検討
3. **自動スケーリング**: ワークロードに応じた動的なリソース調整
### その他のコスト削減機会
1. **バックアップストレージの最適化**
- 現在: 1日保持
- 推奨: 7日保持 (コンプライアンス要件)
- 追加コスト: 約$0.14/月 (許容範囲内)
2. **拡張モニタリングの調整**
- 現在: 60秒間隔
- オプション: 300秒間隔に変更で$5.76/月削減
- 推奨: セキュリティ上、現状維持
3. **データ転送コストの監視**
- 現在: 最小
- 推奨: クロスリージョンレプリケーションを避ける
---
# 📋 優先順位付けされたアクションプラン
### 🔴 緊急 (24時間以内) - Critical
#### セキュリティ
```bash
# 1. 削除保護を有効化
aws rds modify-db-cluster \
--db-cluster-identifier riv-2025-305-rds \
--deletion-protection \
--region us-west-2
# 2. バックアップ保持期間を7日に延長
aws rds modify-db-cluster \
--db-cluster-identifier riv-2025-305-rds \
--backup-retention-period 7 \
--region us-west-2
# 3. CloudWatch ログを有効化
aws rds modify-db-cluster \
--db-cluster-identifier riv-2025-305-rds \
--cloudwatch-logs-export-configuration \
'{"EnableLogTypes":["error","slowquery","audit","general"]}' \
--region us-west-2
期待される成果:
- データ損失リスクの軽減
- コンプライアンススコアが35→60に向上
- セキュリティスコアが45→55に向上
コスト影響: +$2-5/月 (ログストレージ)
運用
# 4. データベース接続の確認
# アプリケーションチームと連携して接続状況を確認
# セキュリティグループルールの検証
期待される成果:
- 未使用リソースの特定
- コスト最適化の方向性決定
🟠 高優先度 (1週間以内) - High
セキュリティ
# 5. IAM データベース認証を有効化
aws rds modify-db-cluster \
--db-cluster-identifier riv-2025-305-rds \
--enable-iam-database-authentication \
--region us-west-2
# 6. Performance Insights を有効化
aws rds modify-db-instance \
--db-instance-identifier riv-2025-305-rds-instance-1 \
--enable-performance-insights \
--performance-insights-retention-period 7 \
--region us-west-2
aws rds modify-db-instance \
--db-instance-identifier riv-2025-305-rds-instance-2 \
--enable-performance-insights \
--performance-insights-retention-period 7 \
--region us-west-2
# 7. スナップショットのタグコピーを有効化
aws rds modify-db-cluster \
--db-cluster-identifier riv-2025-305-rds \
--copy-tags-to-snapshot \
--region us-west-2
期待される成果:
- セキュリティスコアが55→65に向上
- パフォーマンス監視の強化
- 監査証跡の改善
コスト影響: +$7-10/月 (Performance Insights)
ネットワーク
# 8. VPC エンドポイントの作成
# RDS, CloudWatch, KMS 用のエンドポイントを作成
aws ec2 create-vpc-endpoint \
--vpc-id vpc-0e0aabfd9581cd0a6 \
--service-name com.amazonaws.us-west-2.rds \
--route-table-ids rtb-0c112c7c056603497 \
--region us-west-2
期待される成果:
- AWS サービスへの安全な接続
- パッチ適用とアップデートの実現
コスト影響: +$7.20/月 (VPCエンドポイント × 3)
コスト最適化
# 9. インスタンスサイズの変更 (接続が確認できない場合)
# または、クラスターの停止を検討
aws rds modify-db-instance \
--db-instance-identifier riv-2025-305-rds-instance-1 \
--db-instance-class db.r7g.medium \
--apply-immediately \
--region us-west-2
aws rds modify-db-instance \
--db-instance-identifier riv-2025-305-rds-instance-2 \
--db-instance-class db.r7g.medium \
--apply-immediately \
--region us-west-2
期待される成果:
- 月額$182の削減
- 適切なリソースサイジング
コスト影響: -$182/月
🟡 中優先度 (1ヶ月以内) - Medium
セキュリティ
# 10. カスタマーマネージド KMS キーへの移行
# 新しいKMSキーを作成し、スナップショットから復元
# 11. Activity Stream の有効化 (コンプライアンス要件による)
aws rds start-activity-stream \
--resource-arn arn:aws:rds:us-west-2:061039786916:cluster:riv-2025-305-rds \
--mode async \
--kms-key-id <customer-managed-key-id> \
--region us-west-2
# 12. セキュリティグループルールの見直し
# アプリケーションサーバーからの接続を明示的に許可
期待される成果:
- セキュリティスコアが65→75に向上
- コンプライアンススコアが60→75に向上
- 完全な監査証跡の実現
コスト影響: +$10-15/月 (Activity Stream)
運用
# 13. CloudWatch アラームの設定
aws cloudwatch put-metric-alarm \
--alarm-name riv-2025-305-rds-cpu-high \
--alarm-description "CPU utilization exceeds 80%" \
--metric-name CPUUtilization \
--namespace AWS/RDS \
--statistic Average \
--period 300 \
--threshold 80 \
--comparison-operator GreaterThanThreshold \
--evaluation-periods 2 \
--dimensions Name=DBClusterIdentifier,Value=riv-2025-305-rds \
--region us-west-2
# 14. バックアップ保持期間を30日に延長 (本番環境の場合)
aws rds modify-db-cluster \
--db-cluster-identifier riv-2025-305-rds \
--backup-retention-period 30 \
--region us-west-2
期待される成果:
- プロアクティブな監視
- コンプライアンススコアが75→85に向上
コスト影響: +$0.60/月 (バックアップストレージ)
🟢 低優先度 (3ヶ月以内) - Low
最適化
# 15. Aurora Serverless v2 への移行評価
# ワークロードパターンを分析し、適切性を判断
# 16. リザーブドインスタンスまたは Savings Plans の購入
# 継続的な使用が確定した場合
# 17. マイナーバージョン自動アップグレードの無効化 (本番環境)
aws rds modify-db-cluster \
--db-cluster-identifier riv-2025-305-rds \
--no-auto-minor-version-upgrade \
--region us-west-2
期待される成果:
- 長期的なコスト削減
- 計画的なメンテナンス
コスト影響: -$1,336 - $2,230/年 (RI/SP)
📊 実装タイムラインとマイルストーン
Week 1: 緊急対応
- Day 1: 削除保護、バックアップ保持期間、CloudWatch ログ
- Day 2-3: データベース接続の調査
- Day 4-5: セキュリティグループの見直し
- Day 6-7: 初期レビューとステータス報告
マイルストーン: セキュリティスコア 55/100 達成
Week 2-4: セキュリティ強化
- Week 2: IAM認証、Performance Insights、タグコピー
- Week 3: VPCエンドポイント、ネットワーク最適化
- Week 4: コスト最適化の実装
マイルストーン: セキュリティスコア 65/100、月額コスト$189達成
Month 2-3: コンプライアンスと最適化
- Month 2: KMSキー移行、Activity Stream
- Month 3: 監視強化、長期的なコスト戦略
マイルストーン: セキュリティスコア 75/100、コンプライアンススコア 75/100
💡 推奨事項サマリー
即座に実施すべき項目 (ROI: 高)
- ✅ 削除保護の有効化 (リスク軽減)
- ✅ バックアップ保持期間の延長 (コンプライアンス)
- ✅ CloudWatch ログの有効化 (監査証跡)
- ✅ データベース接続の確認 (コスト最適化)
短期的に実施すべき項目 (ROI: 中-高)
- ✅ IAM データベース認証 (セキュリティ)
- ✅ Performance Insights (運用効率)
- ✅ VPC エンドポイント (ネットワークセキュリティ)
- ✅ インスタンスサイズ変更 (コスト削減)
中長期的に検討すべき項目 (ROI: 中)
- ⚠️ カスタマーマネージド KMS キー (コンプライアンス)
- ⚠️ Activity Stream (監査)
- ⚠️ Aurora Serverless v2 (コスト最適化)
- ⚠️ Savings Plans (長期コスト削減)
📈 期待される成果
セキュリティとコンプライアンス
- 現在: セキュリティスコア 45/100、コンプライアンススコア 35/100
- 1週間後: セキュリティスコア 55/100、コンプライアンススコア 60/100
- 1ヶ月後: セキュリティスコア 65/100、コンプライアンススコア 75/100
- 3ヶ月後: セキュリティスコア 75/100、コンプライアンススコア 85/100
コスト最適化
- 現在: $371.64/月 ($4,459.68/年)
- 短期 (インスタンスサイズ変更): $189.84/月 ($2,278.08/年) - 49%削減
- 中期 (Aurora Serverless v2): $108/月 ($1,296/年) - 71%削減
- 長期 (Savings Plans): $185.82/月 ($2,229.84/年) - 50%削減
運用効率
- 監視の改善: Performance Insights、CloudWatch ログ、カスタムアラーム
- インシデント対応時間: 50%短縮 (推定)
- コンプライアンス監査: 自動化された証跡により80%効率化
🎯 結論
RDS クラスター「riv-2025-305-rds」は、技術的には健全ですが、セキュリティ、コンプライアンス、コスト効率において重大なギャップがあります。
主要な懸念事項
- 未使用リソース: データベース接続が0で、月額$371が無駄になっている可能性
- セキュリティギャップ: 監査ログ無効、削除保護なし、バックアップ保持期間1日
- コンプライアンス違反: PCI-DSS、HIPAA、SOC2の要件を満たしていない
推奨される次のステップ
- 即座: 削除保護、バックアップ保持期間、CloudWatch ログを有効化
- 1週間以内: データベース接続を確認し、コスト最適化の方向性を決定
- 1ヶ月以内: セキュリティ強化とコンプライアンス対応を完了
期待される投資対効果
- セキュリティ投資: +$24-30/月
- コスト削減: -$182-263/月
- ネット効果: -$152-239/月 (41-64%削減)
- リスク軽減: データ損失、コンプライアンス違反、セキュリティ侵害のリスクを大幅に軽減
📞 次のアクション
承認が必要な項目
- ✅ 緊急セキュリティ修正の実施 (24時間以内)
- ✅ インスタンスサイズ変更またはクラスター停止の決定 (1週間以内)
- ⚠️ 長期的なコスト最適化戦略の承認 (1ヶ月以内)
関係者への連絡
- セキュリティチーム: セキュリティギャップの報告と修正計画の共有
- アプリケーションチーム: データベース接続の確認と調整
- 財務チーム: コスト最適化の機会と投資対効果の報告
- コンプライアンスチーム: コンプライアンスギャップと修正計画の報告
レポート作成者: Amazon Q
レポート日時: 2025年12月4日 20:55 UTC
次回レビュー: 2025年12月11日 (1週間後)
今回はタスク1しか実行できませんでしたが、自然言語を利用するだけでここまでまとめてくれるのか..!とびっくりしました。
おわりに
今回のワークショップで、CloudWatch MCP と Amazon Q CLI を活用する方法を学ぶことができました!
今まで時間がかかっていたレポートの作成が、短時間で完了する点は驚きでした。
MCPを利用しているので、ハルシネーションも少なそうですね。
CloudWatch MCP はこれまで業務で利用したことなかったので、取り入れていきたいと思いました!
最後までお読みいただきありがとうございました!
どなたかのお役に立てれば幸いです。
以上、おつまみ(@AWS11077)でした!








