CloudWatch アラーム設計ツール

CloudWatchアラームは以下の4要素で定義されます。

• メトリクス: 監視対象の数値（CPU使用率、リクエスト数など）
• 統計: Average（平均）、Sum（合計）、Maximum（最大）など、メトリクスをどう集計するか
• 期間: 集計する時間枠（60秒、300秒など）
• 評価期間 × データポイント: 連続で条件を満たしたらアラート発報

例: 「CPU使用率（メトリクス）のAverage（統計）が5分間（期間）で3回連続（評価期間）80%を超えたら発報」

• 統計の選択: CPU使用率などはAverage、リクエスト数・エラー数はSum、最大負荷の監視はMaximumが基本です。
• 評価期間を長くする: ノイズが減り、誤発報が少なくなる代わりに検知が遅くなります。本番の重要なアラームは「3回中3回」のように複数データポイントで判定すると安定します。
• 評価期間を短くする: 異常をすぐ検知できますが、一時的なスパイクでも発報しやすくなります。
• 期間60秒: CloudWatchの標準解像度では最小1分単位です。それ以下は「高解像度メトリクス（追加料金）」が必要です。

• メトリクスがない状態の扱い: 「missing」の挙動を設定し忘れると、データが来なくなった時（EC2が停止したなど）に無限に発報し続けたり、逆に気づけなかったりします。
• アラームの数=コスト: アラーム1つにつき月$0.10程度。数百個作ると見過ごせないコストになります。まとめられるものはまとめて。
• SNSトピックとサブスクリプションの混在: アラームからSNSへ、SNSからLambdaやメールへ、の二段構成が基本。直接Lambda呼び出しもできますが、通知先の拡張性を考えるとSNS経由が無難です。
• 複合アラームを使えば発報を集約できる: 2026年時点では複合アラームで「このメトリクスとあのメトリクスの両方がしきい値超過」というAND条件を作れます。単純アラームの量産を避けられます。