CloudWatchダッシュボードの作り方｜SREが最初に作るべき5種類とウィジェット設定

AWS監視・オブザーバビリティ

CloudWatchにメトリクスやアラームを設定したのに、障害が起きると「どの画面を見ればいいか」を探すところから始まっていませんか？

サービスごと・担当者ごとにバラバラなダッシュボードが乱立し、インシデント発生時に「あの数値はどこで確認できるんだっけ」と焦る状況が続くと、初動対応が遅れ、復旧時間（MTTR）が長くなります。SRE転職を目指す場合、ダッシュボード設計スキルは面接でも実務でも問われる重要な領域です。

本記事では、CloudWatchダッシュボードの作成手順から、SREが実践する見やすいUI設計のコツまで解説します。

この記事でわかること

  • CloudWatchダッシュボードの種類と料金
  • SREが最初に作るべきダッシュボード5種とその設計方針
  • カスタムダッシュボードの作成手順（ウィジェット設定含む）
  • 再利用性を高めるVariables機能の使い方
  • TerraformでダッシュボードをIaC管理する方法

前提条件

AWS CloudWatch dashboard overview showing automatic service dashboard on the left and custom dashboa

CloudWatchダッシュボードとは

CloudWatchダッシュボードは、メトリクス・アラーム・ログ・テキストなどを1画面にまとめて表示できる カスタマイズ可能な監視画面 です。リージョンをまたいだリソースを1つのビューで確認でき、チーム全員が同じ画面を参照できます。

自動ダッシュボードとカスタムダッシュボードの違い

CloudWatchのダッシュボードには2種類あります。

種類 説明 向いているケース
自動ダッシュボード AWSが自動生成。EC2・Lambda・RDS等のサービスごとに用意 サービス単体の標準的な確認
カスタムダッシュボード ユーザーが自由に設計 インシデント対応・SLO監視・チーム共有

自動ダッシュボードは CloudWatch > ダッシュボード > サービスダッシュボード から確認できます。サービスを選択すると、AWSが主要メトリクスを自動でレイアウトした画面が表示されます。

カスタムダッシュボードは、複数サービスのメトリクスを横断的に見たい場合や、SLO達成率・エラーバジェットを並べて確認したい場合に使います。

ダッシュボードの料金

内容 料金
最初の3ダッシュボード（各50メトリクスまで） 無料
4つ目以降 1ダッシュボードあたり月$3.00

小規模なチームであれば無料枠で運用できます。本番・ステージング・SLO監視など用途を絞ることで、無料枠内に収めることも可能です。

ダッシュボードを整備すると何が変わるか

ダッシュボードが整備されていると、インシデント発生時に以下の変化が生まれます。

  • 初動が速くなる：「どの画面を開けばいいか」を考える時間がゼロになる
  • 属人化が減る：チーム全員が同じ情報源を参照できる
  • SLO違反を素早く検知できる：エラーバジェットの残量をリアルタイムで確認できる
  • Runbookへのアクセスが速くなる：テキストウィジェットで手順書リンクを埋め込める
Five CloudWatch dashboard cards labeled

SREが最初に作るべきダッシュボード5種

ダッシュボード設計の基本方針：1ダッシュボード1目的

ダッシュボードにすべての情報を詰め込むと、見づらくなり結局誰も使わなくなります。1つのダッシュボードに1つの目的 を割り当てることが、長期的に機能するダッシュボード設計の鉄則です。

graph TD

  A["監視ダッシュボード群"] --> B["サービスヘルス
（障害対応時に開く）"]

  A --> C["SLO/エラーバジェット
（日次確認用）"]

  A --> D["インフラリソース
（容量計画用）"]

  A --> E["コスト監視
（月次レビュー用）"]

  A --> F["オンコール概要
（当直担当者用）"]

SREが作るべきダッシュボード5種

# ダッシュボード名 含めるウィジェット 確認タイミング
1 サービスヘルス ALBエラー率・レイテンシー・アラーム状態 障害発生時・常時
2 SLO/エラーバジェット SLO達成率・エラーバジェット残量・バーンレート 毎日
3 インフラリソース EC2 CPU/メモリ・RDS接続数・ECSタスク数 容量計画・スケール判断時
4 コスト監視 AWS請求額トレンド・サービス別コスト 月1回
5 オンコール概要 アクティブアラーム一覧・最近のログエラー 当直開始時

最初に作るなら ①サービスヘルス と ②SLO/エラーバジェット の2つです。障害対応とSLO管理に直結するため、ROIが最も高くなります。

ウィジェットの種類と使い分け

CloudWatchダッシュボードで使えるウィジェットは6種類あります。

ウィジェット種類 説明 適した用途
折れ線グラフ 時系列でメトリクスを表示 CPU使用率・レイテンシーのトレンド確認
数値 最新値を大きく表示 現在のエラー率・リクエスト数の一目確認
アラームステータス アラームのOK/ALARM/INSUFFICIENT状態を色で表示 インシデント発生の即時確認
ログテーブル Logs Insightsクエリ結果を表形式で表示 最新エラーログの一覧
テキスト Markdownでテキスト・リンクを表示 Runbook・手順書リンクの埋め込み
エクスプローラー タグでフィルタしてリソースを動的表示 複数EC2インスタンスの一括確認
AWS CloudWatch console showing

CloudWatchカスタムダッシュボードの作成手順

Step 1：ダッシュボードを作成する

AWSコンソールの CloudWatch > ダッシュボード > ダッシュボードの作成 をクリックします。

  1. ダッシュボード名を入力（例: service-health-prod）
  2. 「ダッシュボードの作成」をクリック
  3. ウィジェット追加のダイアログが表示される

命名規則の推奨：

{環境}-{目的}
例:
  prod-service-health    # 本番のサービスヘルス
  prod-slo-dashboard     # 本番のSLO管理
  dev-infra-resources    # 開発のインフラリソース

環境プレフィックス（prod/stg/dev）をつけると、複数環境のダッシュボードが増えた際に管理しやすくなります。

Step 2：ウィジェットを追加する

アラームステータスウィジェットの追加

インシデント対応時に最初に確認するウィジェットです。アラームの状態を色（緑/赤/グレー）で表示します。

  1. 「ウィジェットを追加」→「アラームステータス」を選択
  2. 表示するアラームを選択（ALBの5xxエラーアラーム・レイテンシーアラーム等）
  3. タイトルを入力（例: 本番サービスのアラーム状態）

配置のコツ： アラームステータスウィジェットはダッシュボードの 左上 に配置します。画面を開いた瞬間に異常の有無がわかるためです。

折れ線グラフウィジェットの追加（ALBエラー率の例）

1. 「ウィジェットを追加」→「折れ線グラフ」を選択
2. 「メトリクス」タブで以下を選択:
   - 名前空間: AWS/ApplicationELB
   - メトリクス: HTTPCode_ELB_5XX_Count / RequestCount
3. 「数式を追加」で以下の式を入力:
   m1 / m2 * 100
   （m1 = 5xxカウント、m2 = 総リクエスト数）
4. 単位を「パーセント」に設定
5. タイトル: 「5xxエラー率 (%)」

数値ウィジェットの追加（レイテンシーP99の例）

1. 「ウィジェットを追加」→「数値」を選択
2. メトリクス選択:
   - 名前空間: AWS/ApplicationELB
   - メトリクス: TargetResponseTime
3. 統計: p99
4. タイトル: 「P99レイテンシー (秒)」

テキストウィジェットでRunbookリンクを埋め込む

インシデント発生時にすぐ手順書を参照できるよう、テキストウィジェットにリンクを貼り付けます。

## 障害対応 Runbook

- [ALB 5xxエラー対応手順](https://notion.so/your-runbook)
- [RDS接続エラー対応手順](https://notion.so/your-runbook)
- [ECSタスク停止時の対応](https://notion.so/your-runbook)

**エスカレーション先**
- L1: #sre-oncall（Slack）
- L2: 担当SREマネージャー

Step 3：Variables（変数）を設定して再利用可能にする

Variables を設定すると、ダッシュボード上部にドロップダウンが表示され、環境やインスタンスを切り替えながら同じダッシュボードを使い回せます。本番・ステージングで別々のダッシュボードを作る手間がなくなります。

設定手順：

  1. ダッシュボードの「アクション」→「変数を管理」をクリック
  2. 「変数を追加」→ 以下を設定：
項目 設定例
変数名 env
ラベル 環境
タイプ 「パターン」
パターン prod\|stg\|dev
デフォルト値 prod
  1. ウィジェットのメトリクス名に ${env} を含める形で参照
{
  "metrics": [
    ["AWS/ApplicationELB", "RequestCount", "LoadBalancer", "${env}-alb"]
  ]
}
Terraform code editor on the left showing aws_cloudwatch_dashboard resource definition, and the resu

SREが実践するダッシュボード設計のコツ

ウィジェットの並び順は「左上が最重要」

画面を開いた瞬間に状態を把握できるよう、ウィジェットの配置に優先度をつけます。

┌─────────────────┬────────────────────┐
│ アラームステータス │ 5xxエラー率（折れ線） │  ← 最重要: 左上に配置
├─────────────────┼────────────────────┤
│ P99レイテンシー  │ スループット         │  ← 重要指標
├─────────────────┴────────────────────┤
│ Runbook リンク（テキストウィジェット）   │  ← 対応補助
└──────────────────────────────────────┘

人間の視線は左上→右→下に流れます。異常検知に最も使うアラームステータスを左上に、次に重要なエラー率を右上に配置することで、インシデント発生時の初動が数秒速くなります。

時間範囲のデフォルトは3時間に設定する

ダッシュボードのデフォルト時間範囲は 3時間 が実務的にバランスが取れています。

  • 15分〜1時間: 直近の詳細確認には良いが、トレンドが見えない
  • 3時間（推奨）: 障害の発生前後の変化とトレンドを両方確認できる
  • 24時間〜: 大局的な確認に良いが、短期スパイクが埋もれる

設定方法：ダッシュボード右上の時間選択で「カスタム」→「3h」を選択 → 「デフォルトとして保存」。

TerraformでダッシュボードをIaC管理する

ダッシュボードをコンソールで手動作成すると、環境間のコピーや変更履歴の管理が難しくなります。Terraformを使ってコードで管理することで、本番・ステージングへの一括適用と変更レビューが可能になります。

resource "aws_cloudwatch_dashboard" "service_health" {
  dashboard_name = "${var.env}-service-health"

  dashboard_body = jsonencode({
    widgets = [
      {
        type   = "alarm"
        x      = 0
        y      = 0
        width  = 12
        height = 6
        properties = {
          title = "アラーム状態"
          alarms = [
            aws_cloudwatch_metric_alarm.alb_5xx.arn,
            aws_cloudwatch_metric_alarm.alb_latency.arn,
          ]
        }
      },
      {
        type   = "metric"
        x      = 12
        y      = 0
        width  = 12
        height = 6
        properties = {
          title  = "5xxエラー率 (%)"
          period = 60
          metrics = [
            ["AWS/ApplicationELB", "HTTPCode_ELB_5XX_Count",
              "LoadBalancer", "${var.env}-alb",
              { id = "m1", visible = false }],
            ["AWS/ApplicationELB", "RequestCount",
              "LoadBalancer", "${var.env}-alb",
              { id = "m2", visible = false }],
            [{ expression = "m1/m2*100", label = "5xxエラー率", id = "e1" }]
          ]
        }
      }
    ]
  })
}

Terraformで管理すると、ダッシュボード定義がGitで管理されます。変更時はPRレビューを通すことで「なぜこのウィジェットを追加したか」の意図が残り、チームの共有資産として機能します。

まとめ

本記事のポイントを整理します。

  • 1ダッシュボード1目的 が設計の基本。詰め込みすぎない
  • 最初に作るべきは2つ：サービスヘルスダッシュボードとSLO/エラーバジェットダッシュボード
  • ウィジェットは左上が最重要：アラームステータスを左上に配置して初動を速くする
  • テキストウィジェット でRunbookリンクをダッシュボードに埋め込むと、インシデント対応が一画面で完結する
  • Variables を使うと環境別に使い回せるダッシュボードを作れる
  • Terraform で管理するとコードレビュー・環境間コピーが楽になる

CloudWatch入門 → アラーム設定 → CloudWatch Logs → Logs Insightsクエリ → SLI/SLO設計 → 本記事（ダッシュボード）の順で読むことで、CloudWatchを使った監視設計の全体を体系的に習得できます。

CloudWatch監視設計を体系的に学ぶ

ダッシュボード設計・アラーム設計・SLO管理・インシデント対応フローをひとつながりで学びたい方は、Udemyコース 「AWS×SRE入門〜CloudWatchで学ぶ監視設計の基礎〜」 をご確認ください。

実務に直結した内容をずんだもん解説で学べます。

AWS×SRE入門コースを見てみる →

コメント

タイトルとURLをコピーしました