【CloudWatchの役割（パフォーマンス最適化）】
目次
🔍 1. 結論
💎 一言でいうと Amazon CloudWatch は、システム全体のパフォーマンスを可視化するサービスですが、高性能設計においては 「高解像度メトリクス（High-Resolution Metrics）」 を活用し、負荷スパイクに対して秒単位でAuto Scalingを発動させる トリガーとして機能します。
- 標準メトリクスは「5分間隔」、詳細モニタリングは「1分間隔」。
- カスタムメトリクスを使えば「1秒間隔」での超高精度な監視が可能。
📈 2. SAAで出やすいポイント
- 詳細モニタリング (Detailed Monitoring): EC2のデフォルトの監視（標準）は5分間隔でデータが取得されます。しかし、急激なトラフィック増（スパイク）に対して5分後の反応ではパフォーマンスが低下してしまいます。追加料金を払って詳細モニタリングを有効にすると、1分間隔でデータが取得され、より機敏にAuto Scalingが発動します。
- 高解像度カスタムメトリクス: CloudWatchエージェント等を使って独自のメトリクス（メモリ使用率など）を送る場合、最小 1秒間隔 の高解像度メトリクスとして記録できます。アラームも最短10秒で評価されるため、極めてシビアなパフォーマンス要件に対応できます。
- パフォーマンス最適化の指標: 「CPU使用率」「ネットワークIn/Out」「ディスクI/O」などの推移を分析し、EC2のインスタンスサイズが適切か、EBSのタイプを変更すべきかを判断するデータソースとなります。
🗝 3. キーワードでの判断
| 問題文のキーワード | 疑う機能・設定 |
|---|---|
| ⏱️ 「Auto Scalingの反応が遅い（スパイクに間に合わない）」 | EC2の詳細モニタリング（1分間隔）を有効にする |
| 🚀 「10秒以内に異常を検知してアクションを起こしたい」 | 高解像度メトリクス (High-Resolution Metrics) |
| 📊 「EC2の『メモリ使用率』や『ディスク空き容量』に基づいてスケールしたい」 | CloudWatchエージェントによるカスタムメトリクス |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「EC2のメモリ使用率を標準のCloudWatchメトリクスで監視する」 → EC2の「標準メトリクス」で取得できるのはCPU、ネットワーク、ディスクI/O（ハイパーバイザーから見えるもの）のみです。OS内部の情報である「メモリ使用率」はカスタムメトリクスとしてエージェントから送信する必要があります。 – CloudTrail との混同: 「誰がAPIを実行したか（監査）」はCloudTrail、「システムのCPUが何%か（パフォーマンス・状態）」はCloudWatchです。
💡 5. 覚え方
🧠 暗記ショートカット – 標準モニタリング = 「5分に1回見回りに来る警備員」。火事（スパイク）に気づくのが遅い。 – 詳細モニタリング = 「1分に1回見回りに来る警備員」。 – 高解像度カスタム = 「1秒単位で監視する防犯カメラ」。
📚 6. 関連サービス
| アイコン | サービス名 | 高性能化における連携 |
|---|---|---|
| 📈 | Auto Scaling | CloudWatchのアラーム（例：CPUが70%を超えた）をトリガーにして、自動でサーバーを増やす |
| 💻 | Amazon EC2 | CloudWatchが監視する対象の代表格 |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: 監視アーキテクチャ、Auto Scalingのトリガー条件学習時
- 関連ノート候補:
AWS_SAA_CloudWatch_Metrics,AWS_SAA_Detailed_Monitoring
8. HTMLファイル名:
AWS_高性能設計_CloudWatch.html
