MENU
AWSを中心としたクラウドインフラ技術サイト
  1. ホーム
  2. AWS
  3. Amazon CloudWatch

Amazon CloudWatch

AWS AWS認定試験

目次

Amazon CloudWatch の特徴

Amazon CloudWatch は、AWS 環境やアプリケーションの状態を監視するためのサービスです。

一言で表すと、AWS 環境の「計器盤・監視カメラ・警報装置」をまとめたサービスです。

CloudWatch は、シンプルに CPU 使用率などを見るだけのサービスではありません。主に次の情報を扱います。

  • 数値としての状態：メトリクス
  • 文字としての記録：ログ
  • 異常を判定する仕組み：アラーム
  • 状態を一覧表示する画面：ダッシュボード
  • アプリケーションやインフラの可観測性：APM、トレース、異常検知など

CloudWatch はメトリクス、アラーム、ダッシュボード、ログなどを利用して、アプリケーションとインフラストラクチャの運用状態を可視化するサービスとして説明されています。

CloudWatch の全体像

CloudWatch の基本的な流れは次のようになります。

EC2、RDS、Lambda、ALB、ECS など
            │
            │ 状態を送信
            ▼
      CloudWatch Metrics
       CloudWatch Logs
            │
            ├── グラフに表示
            ├── Logs Insightsで検索
            ├── Dashboard に集約
            └── Alarm で異常判定
                       │
                       ▼
                 SNS で通知
                 Lambda 実行
                 EventBridge 連携
                 Auto Scaling 実行

たとえば、EC2 の CPU 使用率が高くなった場合は、次のような構成になります。

EC2
 │ CPUUtilization を送信
 ▼
CloudWatch Metrics
 │
 ▼
CloudWatch Alarm
「CPU 使用率が5分間80%を超えたか？」
 │
 ▼
SNS
 │
 ▼
メール・Chatbot・外部通知

重要なのは、CloudWatch が直接すべてを監視しているというより、各 AWS サービスや CloudWatch Agent から送られてきた監視データを、CloudWatch が保存・集計・判定するという仕組みです。

メトリクス（Metrics）とは

メトリクスとは、時間の経過とともに記録される数値です。ある対象の状態を、時間ごとの数値として記録したものです。

例としては、次のようなものがあります。

項番AWSサービスメトリクスの例
1EC2CPUUtilization、NetworkIn、NetworkOut
2RDSCPUUtilization、DatabaseConnections、FreeStorageSpace
3LambdaInvocations、Errors、Duration、Throttles
4ALBRequestCount、HTTPCode_Target_5XX_Count、TargetResponseTime
5ECSCPUUtilization、MemoryUtilization
6S3NumberOfObjects、BucketSizeBytes
7WAFAllowedRequests、BlockedRequests

たとえば EC2 の CPU 使用率は、次のようなデータとして保存されます。

15:00 CPUUtilization = 20%
15:01 CPUUtilization = 35%
15:02 CPUUtilization = 82%
15:03 CPUUtilization = 91%

これは単なる「CPU使用率」という数値ではなく、

いつ
どの対象が
どの項目について
どの値だったか

を継続的に記録したデータです。

メトリクスは、メトリクス名、名前空間、ディメンションなどの組み合わせによって識別されます。メトリクスは多数の項目の組み合わせです。

名前空間：Namespace

名前空間は、メトリクスを分類する大きな箱です。

例：

AWS/EC2
AWS/RDS
AWS/Lambda
AWS/ApplicationELB
AWS/ECS
CWAgent

EC2のメトリクスは通常、次の名前空間に入ります。

AWS/EC2

CloudWatch Agent が送信する OS 内部のメトリクスは、標準では次の名前空間に入ります。

CWAgent

CloudWatch Agent のデフォルトの名前空間はCWAgentですが、設定によって変更できます。

メトリクス名：Metric name

実際に測定する項目です。

例：

CPUUtilization
DatabaseConnections
FreeStorageSpace
Errors
Duration

したがって EC2 の CPU 使用率は、次の組み合わせになります。

Namespace   : AWS/EC2
Metric name : CPUUtilization

ディメンション：Dimension

ディメンションは、どのリソースのメトリクスなのかを識別する条件です。対象を区別する情報です。たとえば、EC2インスタンスが複数ある場合、CPUUtilizationだけではどの EC2 なのか分かりません。

そこで、次のようにインスタンスIDを指定します。ここまで指定して、初めてどの値か分かります。

Namespace   : AWS/EC2
Metric name : CPUUtilization
Dimension   : InstanceId = i-0123456789abcdef0

RDSなら次のようになります。

Namespace   : AWS/RDS
Metric name : CPUUtilization
Dimension   : DBInstanceIdentifier = prod-db-writer

例えるなら、ディメンションは、SQLでいえば絞り込み条件に近いものです。

WHERE InstanceId = 'i-0123456789abcdef0'

Statistic：統計値

一定期間に複数の値（データポイント）がある場合、どのようにまとめるか（集計するか）を指定します。

代表的なものは次のとおりです。

Statistic意味
Average平均値
Maximum最大値
Minimum最小値
Sum合計値
SampleCountデータ数
p90、p95、p99パーセンタイル

たとえば、1分ごとの CPU 使用率が次の値だったとします。

20%, 30%, 40%, 90%, 20%

5分単位で表示すると、

Average = 40%
Maximum = 90%
Minimum = 20%

となります。これを Statistic と言います。

この場合、平均値だけを見ると40%なので正常に見えます。しかし、一時的には90%まで上がっています。

したがって、瞬間的なスパイクを検知したい場合は Maximum も確認することが重要です。一方で、リクエスト数のような回数を確認する場合は、Sumを使うことがあります。

メトリクスと Statistic との関係

メトリクスは元の数値データで、Statistic はその数値をどう集計するかです。

メトリクス
＝ CPU使用率という測定データ

Statistic
＝ 平均・最大・最小などの見せ方

Period：期間

Period は、メトリクスを何秒単位でまとめるかという設定です。

例：

1分
5分
15分
1時間

5分の Period で Average を選択すると、5分間にあるデータポイントの平均値が1つの値として表示されます。CloudWatch は、指定された Period ごとにデータポイントを集約します。

標準メトリクスとカスタムメトリクス

標準メトリクス

AWS サービスが自動的に CloudWatch へ送信するメトリクスです。

たとえば EC2 は、次のような情報を送信します。

CPUUtilization
NetworkIn
NetworkOut
DiskReadBytes
DiskWriteBytes
StatusCheckFailed

EC2 の基本モニタリングでは、通常5分間隔です。詳細モニタリングを有効にすると、1分間隔になります。

EC2のメモリ使用率が見えない理由

EC2 の標準メトリクスでは、通常、OS 内部の次のような情報は取得できません。

メモリ使用率
ディスク使用率
スワップ使用率
プロセス情報
OS内のログ

AWS 基盤側から分かるのは、EC2 仮想マシンの外側の情報だからです。

AWS基盤
 ├── CPU使用量は分かる
 ├── ネットワーク通信量は分かる
 └── 仮想ディスクI/Oは分かる

EC2のOS内部
 ├── メモリ使用量
 ├── /var の空き容量
 ├── Apacheログ
 └── プロセス状態

OS 内部の情報を取得するには、EC2 に CloudWatch Agent をインストールします。CloudWatch Agent は、EC2 やオンプレミスサーバーからメトリクス、ログ、トレースを収集できます。

EC2のOS
 │
 │ CloudWatch Agent
 ▼
CloudWatch Metrics / CloudWatch Logs

カスタムメトリクス

利用者が独自に CloudWatch へ送信するメトリクスです。

たとえば、次のような業務メトリクスを送れます。

ログイン失敗回数
注文数
決済失敗数
暗号化処理の失敗数
バッチ処理件数
未処理ジョブ数

例：

Namespace   : MyApplication
Metric name : PaymentFailureCount
Dimension   : Environment = prod
Value       : 3

アプリケーションからPutMetricData API などを利用して送信できます。カスタムメトリクスは標準解像度だけでなく、1秒粒度の高解像度として発行することもできます。

CloudWatch Logs

CloudWatch Logs は、ログを集約して保存・検索する機能です。

CloudWatch Metrics が数値を扱うのに対して、CloudWatch Logs は文字列や JSON 形式の記録を扱います。

CloudWatch Metrics
CPU使用率 = 85%
エラー件数 = 20件

CloudWatch Logs
2026-06-14 15:01:32 ERROR Database connection timeout

CloudWatch Logs は、AWS サービス、アプリケーション、OS などのログを一か所に集約し、検索・分析できるサービスです。

ロググループ

ロググループは、同じ保持期間、アクセス制御、監視設定などを共有するログのまとまりです。

例：

/aws/lambda/payment-function
/aws/ecs/prod-web
/aws/rds/instance/prod-db/error
/var/log/httpd/access_log

たとえば Lambda では、一般的に関数ごとにロググループが作成されます。

/aws/lambda/function-a
/aws/lambda/function-b

ログストリーム

ロググループの中にある、実際のログ出力元ごとの流れです。

ロググループ
/aws/lambda/payment-function
    │
    ├── ログストリームA
    ├── ログストリームB
    └── ログストリームC

Lambda なら、実行環境ごとにログストリームが作られます。

EC2 の Apache ログなら、次のように構成できます。

ロググループ
/prod/apache/access

ログストリーム
i-11111111111111111
i-22222222222222222
i-33333333333333333

ロググループは、同じ保持期間やアクセス制御を共有するログストリームの集合です。すべてのログストリームは、いずれかのロググループに属します。

ログイベント

ログストリームの中に保存される、1件ずつのログです。

2026-06-14T15:00:01 INFO  Login succeeded user_id=1001
2026-06-14T15:00:10 ERROR Database timeout
2026-06-14T15:00:20 WARN  Retry count exceeded

整理すると、次の階層です。

ロググループ
  └── ログストリーム
        └── ログイベント

ログの保持期間

CloudWatch Logs は、ロググループ単位で保持期間を設定できます。

例：

1日
3日
7日
14日
30日
90日
1年
10年
無期限

保持期間を設定しなければ、ログはデフォルトで無期限に保持されます。そのため、Terraform や CloudFormation でロググループを作る場合は、保持期間を明示することが重要です。

resource "aws_cloudwatch_log_group" "example" {
  name              = "/aws/example/prod"
  retention_in_days = 90
}

保持期間を設定しないと、不要なログが蓄積し続け、料金も増える可能性があります。

CloudWatch Logs Insights

Logs Insights は、CloudWatch Logs に保存されたログを検索・集計する機能です。イメージとしては、CloudWatch Logs 専用の検索・分析ツールです。Logs Insightsでは、ログを対話的に検索・分析して、障害原因の調査や修正確認に利用できます。

たとえば、エラーを新しい順に20件表示する場合は次のように書きます。

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

ステータスコードごとの件数を集計する場合は、次のように書けます。

fields status
| stats count(*) by status
| sort count(*) desc

アクセス元IPごとの件数を調べる例です。

fields clientIp
| stats count(*) as requestCount by clientIp
| sort requestCount desc
| limit 20

Logs Insights は正規表現、比較、計算、集計などをサポートしています。

メトリクスフィルター

メトリクスフィルターとは、ログの中から特定の文字列を見つけ、その件数をメトリクスに変換する仕組みです。

たとえば、アプリケーションログに次の文字列が出るとします。

ERROR Database connection failed

メトリクスフィルターでERRORを検索します。

CloudWatch Logs
      │
      │ "ERROR" を検出
      ▼
Metric Filter
      │
      │ ErrorCount = 1
      ▼
CloudWatch Metrics
      │
      ▼
CloudWatch Alarm

つまり、ログという文字情報を、アラームで判定できる数値情報に変換する機能です。メトリクスフィルターを利用してログ内の文字列やパターンを検出し、それを基にアラームを作成できると説明されています。

たとえば、次のような検知に使えます。

"AccessDenied"
"UnauthorizedOperation"
"Root user"
"ConsoleLogin"
"ERROR"
"OutOfMemoryError"

CloudTrail ログを CloudWatch Logs へ送り、メトリクスフィルターとアラームを組み合わせる構成が重要です。

CloudWatch Alarm

CloudWatch Alarm は、単一の CloudWatch メトリクスを監視する、または複数の CloudWatch メトリクスに基づく数式の結果を監視します。簡単に言うと、メトリクスが設定した条件を満たしたかを判定する機能です。

CloudWatch Alarm は、メトリクスや式の値が複数の期間にわたって特定のしきい値を超えた場合に 1つ以上のアクションを実行します。アクションには、Amazon EC2 アクション、Auto Scaling アクション、Amazon SNS トピックに送信される通知があります。

たとえば、

CPUUtilizationが
5分間の平均で
80%以上になったら
アラーム状態にする

という設定ができます。

アラームの3つの状態

CloudWatch Alarmには、主に3つの状態があります。

状態意味
OK正常
ALARM条件に違反、異常状態
INSUFFICIENT_DATA判定するためのデータ不足（障害とは限らない）

しきい値（閾値）

例：

CPUUtilization >= 80%

この80%がしきい値です。

ただし、実際のアラームでは単純に「一度80%を超えたら通知」とするだけではありません。

次の設定を組み合わせます。

Period
Evaluation periods
Datapoints to alarm
Statistic
Threshold
Missing data treatment

Evaluation periods

何回分のデータを評価するかです。

例：

Period             = 1分
Evaluation periods = 5

この場合、直近5分間を評価します。

Datapoints to alarm

評価対象の中で、何個のデータポイントがしきい値を超えたら ALARM にするかです。

例：

Evaluation periods = 5
Datapoints to alarm = 3

これは、直近 5回のうち 3回がしきい値を超えたら ALARM という意味です。

1分目  70%  OK
2分目  85%  超過
3分目  90%  超過
4分目  75%  OK
5分目  88%  超過

5回中3回が超過したため、ALARMになります。

これは一般に「M out of N」と呼ばれます。

3 out of 5

この設定により、一瞬だけCPUが上がった場合の誤通知を減らせます。

アラームアクション

アラーム状態になった後、CloudWatch Alarm は別のサービスに処理を依頼します。

代表的なアクションは次のとおりです。

SNSへ通知
Auto Scalingポリシーを実行
EC2アクションを実行
Systems Manager OpsCenterへ連携
EventBridgeへ状態変更イベントを送信

例：

CloudWatch Alarm
      │
      ▼
SNS Topic
      │
      ├── メール
      ├── Lambda
      ├── SQS
      └── Chatbot経由の通知

ここで重要なのは、CloudWatch Alarm そのものがメールを送信するわけではない ということです。

通常は CloudWatch Alarm からSNSを呼び出し、SNSがメールなどを配信します。

EC2 インスタンスが異常のステータスになった場合の対処

CloudWatch アラームを利用して、標準メトリクスの「StatusCheckFailed_System」を監視・トリガーしインスタンスを自動的に復旧させることができます。StatusCheckFailed_System は、EC2インスタンスを動かしている AWS側の基盤に問題がないか を表す CloudWatch メトリクスです。

Namespace   : AWS/EC2
Metric name : StatusCheckFailed_System
Dimension   : InstanceId
値           : 0（成功） または 1（失敗）

EC2のステータスチェックは 1分ごとに実行され、失敗すると対応するCloudWatchメトリクスが 1 になります。

「System」はどこを指すのか

ここでいうSystemは、EC2のOS内部ではありません。

利用者が管理する範囲
┌────────────────────┐
│ EC2インスタンス     │
│ ・Linux / Windows  │
│ ・アプリケーション   │
│ ・OS設定            │
└────────────────────┘
          ↑
    仮想化基盤・物理基盤
┌────────────────────┐
│ AWSが管理する範囲    │
│ ・物理ホスト         │
│ ・電源              │
│ ・ネットワーク基盤   │
│ ・仮想化基盤        │
└────────────────────┘

EC2 インスタンスの異常は基盤となるハードウェアの障害の可能性が高いです。

EC2のOS自体は正常かもしれない
        ↓
しかし、EC2を載せている物理ホストや
AWSネットワーク基盤に問題がある
        ↓
StatusCheckFailed_System = 1

EC2 インスタンスを再起動すると、正常な基盤上で起動してくるので、回復アクションは EC2 インスタンスの再起動を選択して復旧させることができます。

CloudWatch エージェント（CloudWatch Agent）

CloudWatch Agent は、EC2 やオンプレミスサーバーなどにインストールするエージェントです。CloudWatch エージェントをインストールすることでデータを CloudWatch へ転送したり、ログを CloudWatch Logs に転送することができます。Agent が CloudWatch や CloudWatch Logs へデータを送信するには、EC2 のインスタンスプロファイル（IAMロール）などに適切な権限が必要です。

主に次の情報を収集します。

メモリ使用率
ディスク使用率
スワップ使用率
プロセス情報
OSログ
アプリケーションログ
トレース

CloudWatch Agent を利用して、EC2 内のログと OS メトリクスを CloudWatch へ送信する構成は、次のようになります。

EC2
├── OSログ
│   ├── /var/log/messages
│   └── /var/log/httpd/access_log
│
├── OSメトリクス
│   ├── メモリ使用率
│   └── ディスク使用率
│
└── CloudWatch Agent
      ├── OSログを収集
      ├── OSメトリクスを収集
      └── AWS CloudWatchへ送信

AWS CloudWatch
├── CloudWatch Logs
│   ├── /var/log/messages
│   └── /var/log/httpd/access_log
│
└── CloudWatch Metrics
    ├── mem_used_percent
    └── disk_used_percent

つまり、CloudWatch Agentは次の役割です。

EC2内の情報
    ↓
CloudWatch Agentが収集
    ↓
CloudWatch LogsまたはCloudWatch Metricsへ送信

CloudWatch エージェントの設定ファイル

CloudWatch Agent（CloudWatch エージェント）の設定ファイルは基本的に JSON 形式で、主に次の2種類を収集する内容を記述します。

  • OSメトリクス　：　メモリ、ディスク使用率、CPU、プロセスなど
  • ログ　：　/var/log/messages やアプリケーションログなど

CloudWatch エージェントは、EC2 が標準で送信していないメモリ使用率やOS内部のディスク使用率を送るために使われます。設定ファイルの中心は、agent、metrics、logs の3セクションです。

設定ファイルは JSON で、以下のように記述します。

{
  "agent": {},
  "metrics": {},
  "logs": {},
  "traces": {}
}

CloudWatch Agent の設定ファイルは、agent、metrics、logs、tracesのセクションで構成されます。

セクション用途
agentAgent 自体の動作設定
metricsOSメトリクスの収集設定
logsログファイルの収集設定
tracesX-Ray や OpenTelemetry のトレース収集

CloudWatch Agent で収集する（収集できる）メトリクスは3種類あります。それぞれについて説明します。

  1. EC2が最初から送信する標準メトリクス
  2. CloudWatch Agentが用意しているOSメトリクス
  3. 自分で作る完全な独自メトリクス

１．EC2が最初から送信する標準メトリクス

CloudWatch Agentをインストールしなくても存在します。

代表例は次のとおりです。

CPUUtilization
NetworkIn
NetworkOut
DiskReadBytes
DiskWriteBytes
StatusCheckFailed
StatusCheckFailed_Instance
StatusCheckFailed_System

名前空間は通常、次のようになります。

AWS/EC2

これらはEC2サービス側が収集しているため、CloudWatch Agent の設定ファイルには書かなくても取得できます。基本監視は通常5分間隔で、詳細モニタリングを有効化すると1分間隔になります。

２．CloudWatch Agentが用意しているOSメトリクス

CloudWatch Agent が用意している OS メトリクスで代表例は以下になります。

mem_used_percent
disk_used_percent
swap_used_percent
cpu_usage_iowait
procstat_lookup_pid_count

これらはCloudWatch Agent自体が対応している、いわば既製の収集項目です。

自分で計算式やプログラムを作る必要はありません。設定ファイルで収集したい項目を選ぶだけです。

"mem": {
  "measurement": [
    "used_percent"
  ]
}

この設定により、次のメトリクスが生成されます。

mem_used_percent

標準の名前空間は次です。

CWAgent

CloudWatch Agent の名前空間は設定で変更できますが、既定値は CWAgent です。つまり、位置付けとしては次のとおりです。

AWS が CloudWatch Agent に実装済みのメトリクスを、利用者が設定ファイルで有効化する

完全な独自開発ではありませんが、CloudWatch 料金上は一般にカスタムメトリクスとして扱われます。

３．自分で作る完全な独自メトリクス

例えば次のような監視です。

/var/www/src/site/storage/logs の合計容量
処理待ちジョブ件数
エラー件数
バッチの最終成功時刻
ログインユーザー数

CloudWatch Agent の通常の disk 設定では、ファイルシステム全体の使用率は取得できます。

disk_used_percent

しかし、特定のディレクトリだけの容量は、そのままでは取得できません。

例えば、Laravel の場合なら

du -sb /var/www/src/site/storage/logs

の結果をスクリプトで取得し、AWS CLI の put-metric-data などで送信します。

SIZE_BYTES=$(du -sb /var/www/src/site/storage/logs | awk '{print $1}')

aws cloudwatch put-metric-data \
  --namespace "Custom/Application" \
  --metric-name "LaravelLogDirectorySize" \
  --dimensions InstanceId="$(curl -s http://169.254.169.254/latest/meta-data/instance-id)" \
  --value "${SIZE_BYTES}" \
  --unit Bytes

これは完全に独自設計したカスタムメトリクスです。CloudWatch では、PutMetricData APIなどを使用して独自メトリクスを送信できます。

CloudWatch エージェントと CloudWatch Logs エージェントの違い

CloudWatch Logs エージェントは CloudWatch エージェントの古いバージョンであり、利用することは可能ですが、CloudWatch エージェントを利用することが推奨されています。

ログの保存期間について

CloudWatch Logs のロググループはログの保持期間を設定することが可能です。保持期間を設定しないとログが無限に保存されることになりコスト増につながります。

CloudWatch Logs メトリクスフィルター

CloudWatch Logs のメトリクスフィルター（Metric Filter）は、ログの中から特定パターンを見つけた回数（または値）を、CloudWatch メトリクスとして作る機能です。ログをメトリクスに変換する機能とも言えます。作ったメトリクスはアラームやダッシュボードなど、普通のメトリクスと同様に使えます。

データ保護ポリシー

ロググループのデータ保護ポリシーを使用することで、CloudWatch Logs に取り込まれた機密データを保護できます。CloudWatch はデータ保護ポリシーを使用して、スキャンする機密データと、そのデータを保護するために実行するアクションを選択します。具体的にはログの中に入ってしまった機密情報を検出して、監査したり、表示時にマスクしたりします。CloudWatch Logs は、データ識別子を使って機密データを検出し、Audit とDe-identify という操作で、検出記録やマスキングを行えます。

マスクされていないデータを閲覧できるのは、logs:Unmask IAMアクセス許可を持つユーザーのみです。

ポリシーはアカウント全体や個別のロググループに対して適用できます。

どのようなデータを保護するのか

例えば、アプリのログにうっかり次のようなものが出てしまうことがあります。

  • クレジットカード番号
  • メールアドレスや氏名などの個人情報
  • AWS シークレットアクセスキー

データ保護ポリシーにより、こうした機密データをマネージドデータ識別子やカスタムデータ識別子で検出できます。対応カテゴリには認証情報、財務情報、PII、PHI、デバイス識別子などがあります。

データ保護ポリシーで何がどうなるのか

データ保護ポリシーにより、以下の2つのデータ保護を実施してくれます。

監査（Audit）

機密データが見つかったことを記録し、AWS/Logs 名前空間に LogEventsWithFindings メトリクスを発行します。このメトリクスは CloudWatch アラームに使えます。つまり、「このロググループで機密情報っぽいものが出た」を監視できるようになります。

マスキング（De-identify）

機密データを、ログ表示時に見えないようにします。しかもマスキングは、CloudWatch Logs Insights、メトリクスフィルター、サブスクリプションフィルターなどの出力ポイントで既定で適用されます。マスクされていない元データを見られるのは、logs:Unmask 権限を持つユーザーだけです。

CloudWatch と EventBridge の違い

この2つが分かりづらい最大の理由は、どちらも「異常や変化を検知して、通知や処理を実行する」ように見えるからです。

まず、役割を一言で分けると次のようになります。

  • CloudWatch は、状態を観測して異常かどうかを判断するサービス
  • EventBridge は、発生した出来事を受け取り、適切な処理先へ振り分けるサービス
CloudWatch
＝ 数値やログを観測する
＝ 状態を判断する

EventBridge
＝ 出来事を受け取る
＝ 条件に合う処理先へ届ける

「状態」と「出来事」で分ける

CloudWatch と EventBridge を理解するには、次の違いが重要です。

状態

状態とは、ある時点または一定期間における数値や状況です。

CPU使用率が90%
RDS接続数が500
ディスク空き容量が10GB
5分間でエラーが20件

これを主に扱うのがCloudWatchです。

出来事

出来事とは、何かが発生したという事実です。

EC2が停止した
ECSタスクが終了した
Lambdaのデプロイが完了した
CloudWatch AlarmがALARMになった
IAM Access Analyzerで検出結果が作成された

これを受け取って振り分けるのが EventBridge です。

CPU使用率を監視する例

たとえば、EC2のCPU使用率が高くなったらLambdaを実行したいとします。

CPU使用率は「出来事」ではなく、時間とともに変化する数値です。

10:00  CPU 40%
10:01  CPU 65%
10:02  CPU 91%
10:03  CPU 93%

この数値を評価するのはCloudWatchです。

EC2
 │ CPUUtilization
 ▼
CloudWatch Metrics
 │
 ▼
CloudWatch Alarm
「2分連続で80%以上か？」
 │
 ▼
ALARM状態
CloudWatch Alarm は、メトリクスを監視し、しきい値を超えたときに通知やリソース操作を実行できます。

さらに、アラーム状態の変化を EventBridge で受け取れます。
CloudWatch Alarm
OK → ALARM
      │
      │ アラーム状態変更イベント
      ▼
EventBridge
      │
      ▼
Lambda

CloudWatch Alarmの状態変更はEventBridgeへイベントとして送信されます。

この場合の役割分担は次のとおりです。

処理担当
CPU使用率を保存するCloudWatch Metrics
80%以上か判定するCloudWatch Alarm
ALARMになったというイベントを受け取るEventBridge
条件に応じてLambdaへ届けるEventBridge
実際の復旧処理をするLambda

つまり、CloudWatch が異常を見つけ、EventBridge がその結果を別の処理へ運ぶという関係です。

CloudWatch Alarm と EventBridge ルールの違い

CloudWatch Alarmの条件

CloudWatch Alarm は、主に数値を条件にします。

CPUUtilization >= 80
Errors >= 10
FreeStorageSpace < 20GB
DatabaseConnections >= 500

また、一定期間や回数も評価できます。

5分間のうち3回以上、CPUが80%を超えた

つまり、数値を時間軸で評価するのが CloudWatch Alarm です。

EventBridgeルールの条件

EventBridge は、イベントに含まれる項目を条件にします。

source が aws.ec2
state が stopped
clusterArn が 本番クラスター
eventName が 特定の値
severity が CRITICAL

つまり、JSON 形式のイベント内容を照合するのが EventBridge ルールです。

比較すると次のようになります。

項目CloudWatch AlarmEventBridge ルール
主な入力メトリクスイベント
条件数値、しきい値、期間JSONの項目や値
時間評価得意基本的にはしない
例CPUが5分間80%以上EC2の状態がstopped
結果OK、ALARM、INSUFFICIENT_DATA一致または不一致
処理通知、EC2操作などターゲットへのルーティング

ログの場合の内部構成

たとえば、アプリケーションログに次の文字が出たら通知したいとします。

ERROR Database connection timeout
この場合、基本的な CloudWatch 構成は次のとおりです。
アプリケーション
        │
        ▼
CloudWatch Logs
        │
        ▼
Metric Filter
ERRORを数値に変換
        │
        ▼
CloudWatch Metrics
ErrorCount = 1
        │
        ▼
CloudWatch Alarm
        │
        ▼
SNS

CloudWatch Logsのメトリクスフィルターは、ログデータを数値のCloudWatchメトリクスへ変換し、そのメトリクスをグラフ化したりアラーム対象にしたりできます。

ここではCloudWatchが、

  1. ログを保存する
  2. ERRORを数える
  3. 一定件数を超えたか判定する

ところまで担当します。

その後、複雑な処理へ振り分けるならEventBridgeを組み合わせられます。

CloudWatch Alarm が ALARM
        │
        ▼
EventBridge
        ├── 本番 なら PagerDuty
        ├── 開発 なら Slack
        └── CRITICAL なら Lambda で復旧

具体的な3つの構成

構成A：CloudWatchだけでよい場合

EC2 CPU使用率
      ↓
CloudWatch Alarm
      ↓
SNS
      ↓
メール通知

要件が、CPU が高ければ管理者へメールするだけなら、EventBridge を挟む必要はありません。

構成B：EventBridgeだけでよい場合

EC2が停止
      ↓
EventBridge
      ↓
SNS

要件が、EC2が停止したら通知するなら、これは状態変更イベントなので、EventBridgeだけで実現できます。

構成C：両方使う場合

RDS FreeStorageSpace
      ↓
CloudWatch Alarm
残容量20GB未満
      ↓
EventBridge
      ├── SNSへ緊急通知
      ├── Lambdaでチケット作成
      └── Step Functionsで対応処理

この場合、

  • CloudWatch：ストレージ残容量が異常か判断
  • EventBridge：異常イベントを複数の処理先に振り分ける

という役割です。

AWS AWS認定試験
Amazon CloudWatch AWS AWS認定試験

関連記事