CloudWatch監視設計、最初に入れるべきアラーム10選

監視の失敗は二極化します。アラームがほぼゼロで「止まってから顧客の電話で知る」環境と、通知が多すぎて「誰も見なくなった」環境。どちらも現場で何度も見てきました。この記事では、私たちが運用を引き受けるとき最初に入れる基本アラーム10個を、しきい値の初期値ごと公開します。ここから始めて、環境に合わせて育ててください。

01大前提：アラームは「アクションできるもの」だけ

設計原則は1つだけです。鳴ったら誰かが何かをする通知だけをアラームにする。「知っておきたいだけ」の情報はダッシュボードに置き、アラームにしない。この線引きを守らないと、通知は数週間でオオカミ少年になります。見なくなった通知は、無いのと同じです。

02基本の10アラーム（しきい値の初期値つき）

• ① EC2 StatusCheckFailed — インスタンス・ホスト異常の検知。1回でも即通知。system側の失敗はEC2の自動復旧アクション（recover）も併せて設定
• ② EC2 CPUUtilization — 80%が15分継続で警告。瞬間値で鳴らさないのがコツ（正常なスパイクまで拾うため）
• ③ ディスク使用率（CloudWatch Agent必須）— 80%警告・90%緊急の2段。ディスク枯渇は「静かに全部を壊す」障害の代表格
• ④ メモリ使用率（同上）— 90%が10分継続で警告。CloudWatch Agentを入れないと③④は見えません。まず入れてください
• ⑤ EBS BurstBalance / VolumeQueueLength — gp2が残る環境はBurstBalance 30%以下で警告（枯渇前に気づく）。詳細はEBS選定の記事へ
• ⑥ RDS FreeStorageSpace — 空き20%で警告、10%で緊急。RDSのストレージ枯渇は復旧に時間がかかる筆頭
• ⑦ RDS CPU・DatabaseConnections — CPU 80%継続、接続数はmax_connectionsの80%で警告
• ⑧ ALB HTTPCode_Target_5XX_Count・TargetResponseTime — 5xxが数分間に一定数（例：5分で10件）で通知。ここが「ユーザーに見えている障害」に最も近い指標です
• ⑨ Lambda Errors・Throttles — Errorsは1件から様子見の警告、Throttlesは即調査。非同期処理はDLQ（デッドレターキュー）の滞留監視も
• ⑩ 請求（Billing / Budgets） — 予算の80%で警告、100%で緊急。不正利用・設定ミスの最初の検知点は請求です

03通知の設計：2段階＋宛先分離

全部を同じチャンネルに流すと、緊急の1件が日常の10件に埋もれます。最低限、次の2段に分けてください。

• 警告（Warning） — 営業時間内に対応すればよいもの → チャットの監視チャンネルへ
• 緊急（Critical） — 業務影響が出ている・出る直前 → 電話やオンコール通知が届く経路へ

SNSトピックを2つ（warning用・critical用）作って各アラームを振り分けるだけで実現できます。「深夜に起こす価値がある通知か」を各アラームに問うのが振り分けの基準です。

04「復旧」も設計に含める

通知して人間が走るだけが監視ではありません。最初に入れる自動化はEC2の自動復旧（StatusCheckFailed_System → recoverアクション）で、設定1つでホスト障害の一次対応が消えます。次がAuto Scalingによる自動置き換え、その先がSSM Automationによる定型復旧です。「鳴る→人が見る→毎回同じ操作をする」通知は、自動化の候補リストだと思ってください。

05ダッシュボードは「朝会で見る1枚」だけ

凝ったダッシュボードは作った人しか見ません。CPU・ディスク・5xx・レスポンスタイム・請求の5枚程度のグラフを1画面に置き、朝会やシフト交代で全員が同じ画面を見る運用にする方が、立派な10画面より事故を防ぎます。

—まとめ

①アクションできる通知だけをアラームにする。②まず基本の10個としきい値の初期値から。③警告と緊急を分け、深夜に起こす価値で振り分ける。④「毎回同じ対応」は自動復旧へ。⑤ダッシュボードは1枚。——監視は高価なツールの話ではなく、設計と習慣の話です。私たちが重大障害5年ゼロを維持できているのも、特別な仕掛けではなく、この基本を月次で回し続けているからです。