はじめに
AWSコスト削減のため、オーバースペックなEC2インスタンスのスペックダウンを検討する際、最も重要な判断は「いつ実施するか」である。特にデータベースサーバーの場合、業務への影響を最小限に抑える必要がある。
本記事では、CloudWatchメトリクスを活用した定量的分析により、深夜対応を最小化しながら安全にスペックダウンを実施できる時間帯を特定した実践事例を紹介します。
課題設定：運用負荷とリスクのバランス
対象は本番環境のサーバー（r6a.2xlarge）であった。コスト削減のためスペックダウンが必要だが、以下の制約がありました。
- 最も利用されていないタイミングでの実施が必須
- 深夜対応は極力避けたい（運用負荷の観点+やりたくないw）
- 業務への影響を最小限に抑える必要がある
単純に「深夜が安全だろう」と推測するのではなく、実データに基づいて客観的に判断する必要があった。
分析手法：総合スコアによる評価
使用ツール
本分析では、Kiro CLIとMCPサーバー（Model Context Protocol）を通じてCloudWatchメトリクスを取得・分析した。Kiro CLIは、AWSが開発したAI統合開発環境のコマンドラインインターフェースであり、MCPサーバーとの連携によりAWSリソースのメトリクス取得などの運用タスクも効率的に実行できる。これから先にまとめている情報はKiro CLIに対して1回の指示で情報の収集から分析・まとめをしてくれたので僕自身の稼働は5~10分ほどで済んでいます。
使用メトリクス
2025年11月の1ヶ月間のCloudWatchメトリクスを分析対象とした
- CPU使用率：平均値と最大値（1時間粒度）
- ネットワーク受信量：データベースへのアクセス量の指標
評価指標の設計
複数のメトリクスを統合的に評価するため、以下の総合スコアを定義した
総合スコア = CPU平均 + (CPU最大 / 2) + (ネットワーク量 / 100)
この指標により、以下を総合的に評価できる
- 平常時の負荷（CPU平均）
- スパイク時の負荷（CPU最大）
- データベースアクセス量（ネットワーク）
分析結果：意外な発見
全体傾向
分析の結果、以下の傾向が明らかになった
- CPU使用率: 全時間帯で平均1-2%と極めて低い
- 明確なパターン: 深夜0-1時が最も負荷が低い
利用が少ない時間帯 TOP 5
| 順位 | 時間帯 | 平均CPU | 最大CPU | ネットワーク | 総合スコア |
|---|---|---|---|---|---|
| 1位 | 00:00-00:59 | 1.02% | 4.39% | 159 MB/h | 4.81 |
| 2位 | 01:00-01:59 | 1.11% | 3.82% | 263 MB/h | 5.65 |
| 3位 | 22:00-22:59 | 1.22% | 4.64% | 248 MB/h | 6.01 |
| 4位 | 17:00-17:59 | 1.23% | 6.88% | 190 MB/h | 6.58 |
| 5位 | 16:00-16:59 | 1.21% | 5.00% | 297 MB/h | 6.68 |
深夜以外の候補時間帯
22:00-22:59（第3位） が最も有望な選択肢である
- 平均CPU: 1.22%
- 最大CPU: 4.64%
- ネットワーク: 248 MB/h
- 評価: 深夜0-1時に次いで安全。22時開始であれば、作業完了は23-24時頃で深夜対応を最小化できる
深夜帯（0-1時）との総合スコア差は小さい（6.01 vs 4.81）ため、リスクは許容範囲内と判断できる。
避けるべき時間帯の特定
分析により、以下の時間帯は絶対に避けるべきであることが判明した
18:00-18:59（最も危険）
- ネットワーク: 7,253 MB/h（7.2GB/h）
- 理由: 業務時間帯で最も負荷が高い。ピークタイムのため絶対に避けるべき
02:00-05:00（バッチ処理時間帯）
- CPU最大: 19-37%のスパイク
- ネットワーク: 900-1,456 MB/h
- 理由: バッチ処理実行中の可能性が高い。スペックダウンによりバッチ処理に影響を与えるリスクがある
08:00、14:00、20:00（定期スパイク）
- CPU最大: 25-31%のスパイク
- 理由: 定期的な処理が実行されている可能性
推奨アプローチ：3つのパターン
パターンA: 最も安全（深夜対応）
- 実施時間: 00:00-00:59
- メリット: 業務影響リスクが最小
- デメリット: 深夜対応が必要
パターンB: 深夜対応を最小化（推奨）
- 実施時間: 22:00-22:59
- メリット: 22時開始であれば、作業完了は23-24時頃で深夜対応を最小化できる
- デメリット: 深夜0-1時と比較するとリスクは若干高いが、許容範囲内
パターンC: 完全に深夜を避ける
- 実施時間: 17:00-17:59
- メリット: 業務時間内に完了可能
- デメリット: 18時台のピークタイムに近く、リスクが高い。18時台の大量トラフィック（7.2GB/h）に注意が必要
最終推奨：22時実施
22:00-22:59の実施を推奨する。
理由は以下の通り
- 深夜0-1時に次いで安全な時間帯（第3位）
- 22時開始であれば、作業完了は23-24時頃で深夜対応を最小化できる
- 深夜帯（0-1時）との総合スコア差は小さい（6.01 vs 4.81）
- 万が一の問題発生時も、深夜帯より対応しやすい
実施時の注意事項
事前準備
- アプリケーションチームへの事前通知（最低24時間前）
- データベース接続の監視体制構築
- ロールバック手順の確認と準備
- 緊急連絡体制の整備
実施中の監視
- CPU使用率のリアルタイム監視
- データベース接続数の監視
- アプリケーションログのエラー監視
- クエリレスポンスタイムの監視
実施後の対応
- 24時間の性能監視強化
- 問題発生時の即座ロールバック体制
- 翌営業日の業務開始時の確認
学びと知見
定量分析の重要性
「深夜が安全だろう」という推測ではなく、実データで検証することで、より正確な判断が可能になる。Kiro CLIとMCPサーバーを活用してCloudWatchメトリクスを効率的に取得・分析することで、1ヶ月間のデータから客観的な傾向を把握できた。
リスクとコストのトレードオフ
最も安全な時間帯（深夜0-1時）と運用負荷（深夜対応）のバランスを考慮し、22時実施により安全性と運用負荷の両立が可能であることが判明した。完全に深夜を避ける（17時実施）はリスクが高いことも明確になった。
バッチ処理の可視化
02:00-05:00のCPUスパイクとネットワーク増加からバッチ処理を特定できた。定期的なスパイク（08:00、14:00、20:00）も可視化され、これらの時間帯を避けることが重要であることが明確になった。
まとめ
CloudWatchメトリクスを活用した定量的分析により、EC2インスタンスのスペックダウン最適タイミングを特定できた。データドリブンなアプローチにより、運用負荷を最小化しながら安全にコスト削減を実施できることが実証された。
重要なのは、推測に頼らず実データに基づいて判断することである。本手法は、他のインスタンスやサービスにも応用可能な汎用的なアプローチである。
参考情報
- 分析環境: EC2インスタンス (r6a.2xlarge)、2025年11月1日-30日のデータ
- データソース: Amazon CloudWatch Metrics
- 使用ツール: Kiro CLI + MCPサーバー（CloudWatchメトリクスの取得・分析）
- 分析手法: 時間帯別の統計集計、総合スコアによる評価