変更要約: in-scope サービス網羅(是正): §4.3 にベストプラクティス横断点検の Trusted Advisor 節を追加（参考書で未説明だった軸B欠落を解消）
4.1メトリックとアラーム
メトリック監視——CloudWatch メトリック（標準/カスタム）、アラーム、複合アラーム、ダッシュボード、EventBridge——を理解します。異常を検知して通知・自動対応につなげます。
監視の基本はメトリックとアラームです。CloudWatch で指標を集め、閾値超過で通知や自動アクションを起動します。
4.1.1CloudWatch メトリックとアラーム
- 標準/カスタムメトリック：標準は自動収集。メモリ等は PutMetricData でカスタム送信。
- アラーム：閾値超過で OK/ALARM/INSUFFICIENT_DATA を遷移し、アクションを起動。
- 複合アラーム：複数アラームを論理結合し、誤検知（ノイズ）を抑える。
- EventBridge 連携：アラームやイベントを受けて SNS 通知/Lambda/Auto Scaling を自動起動。
「メモリ使用率などの取得＝カスタムメトリック（PutMetricData / CloudWatch Agent）」「複数条件の組合せ＝複合アラーム」「アラーム→通知/自動対応＝SNS/EventBridge/Lambda」 は DOP-C02 で頻出です。EC2 のメモリ/ディスクは標準メトリックに無く、CloudWatch Agent で取得します。
DOP-C02 では「ノイズの少ない、行動につながる監視」をどう設計するかが問われます。メトリックには名前空間・ディメンション・解像度（標準1分／高解像度1秒）があり、EC2 のメモリ/ディスクは標準では取れないため CloudWatch Agent でカスタム送信します。アラームは period・evaluation periods・datapoints to alarm（M of N）で短時間スパイクの誤報を抑え、欠損データの扱い（missing data treatment）も指定できます。異常検知（Anomaly Detection）は ML で動的なバンドを学習し、季節変動のある指標でも固定閾値より誤検知を減らせます。複合アラームは複数アラームを AND/OR で結合し、「DB も Web も同時に異常なときだけ通知」のようにアラート疲れを抑制します。アラームのアクションは SNS（通知）・EC2/Auto Scaling アクション・Systems Manager（OpsItem/インシデント）を直接指定でき、より複雑な自動対応は EventBridge ルール→Lambda/SSM Automation/Step Functions に流します。組織横断ではメトリックのクロスアカウント可観測性で監視アカウントに集約します。重要なのは、各アラームを「誰が・何を・どう対処するか（Runbook）」に結びつけ、通知だけで終わらせないことです。
| 要件 | 機能 | 要点 |
|---|---|---|
| 標準に無い指標を取る | カスタムメトリック / Agent | メモリ/ディスク/ビジネス KPI |
| 短時間スパイクの誤報を抑制 | M of N 評価・欠損データ扱い | evaluation/datapoints to alarm |
| 季節変動に追従 | 異常検知 | ML が動的バンドを学習 |
| アラート疲れを減らす | 複合アラーム | 複数条件を AND/OR で結合 |
シナリオ：夜間バッチで CPU が一時的に跳ねるたびにアラームが鳴り、運用が疲弊している。本当に問題のときだけ通知したい。→ アラームを M of N（例: 5 分中 3 データポイント超過）にして瞬間的スパイクを無視し、季節変動には 異常検知バンドを採用。さらに「CPU 高 かつ エラー率 高」を 複合アラームで AND 結合して、本当に劣化しているときだけ SNS 通知します。
FAQ：固定閾値アラームと異常検知はどちらを使う？ 値の正常範囲が一定なら固定閾値が単純で十分。時間帯・曜日で大きく変動する指標（トラフィック等）は固定閾値だと誤検知が増えるため、ML がバンドを学習する異常検知が向きます。両方を使い分け、重大な確定的条件は固定閾値、傾向的な異常は異常検知、という併用も有効です。
ひっかけ：「EC2 のメモリ使用率でアラームを作る」設問で、標準メトリックだけで実現しようとするのは誤り。メモリ/ディスクは標準メトリックに存在しないため、CloudWatch Agent（または PutMetricData）でカスタム送信してからアラーム化します。CPU・ネットワークは標準にありますが、メモリは別、と覚えます。
4.1.2この節のまとめ
- メトリック＝標準＋カスタム（PutMetricData/Agent）
- アラーム＝複合アラーム＋EventBridge/SNS で自動対応
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. EC2 インスタンスのメモリ使用率を監視したい。標準メトリックには無いため、どうしますか？
Q2. 複数のアラームを論理的に組み合わせ、本当に重大なときだけ通知して誤検知を減らしたい。何を使いますか？
Q3. アラームが ALARM 状態になったら、通知に加えて自動で修復用の Lambda を起動したい。何を使いますか？