Amazon CloudWatch アラームをアクション可能なシグナルに変える

本記事は 2026年7月6日に公開された「Turn Your Amazon CloudWatch Alarms into Actionable Signals」を翻訳したものです。

午前2時にアラームが鳴ります。スマートフォンを手に取り、目を細めて通知を見ると、こう書いてあります：「ALARM: my-service-alarm が ALARM 状態に遷移しました。」 コンテキストなし。アプリケーション名なし。200台のインスタンスのうちどれが問題なのか、そもそもそれが重要なのかすら分かりません。

私もそうでした。誰もがこの経験をしたことがあるはずです。

アラームに対する不満は、「何かがおかしい」と「何をすべきか分かっている」の間のギャップから生まれることが多いです。メトリクス名と閾値しか得られないとき、コンテキストは自分で補うしかありません。どのリソースか、どのアプリケーションか、このサービスはどれくらい重要か？

Amazon CloudWatch アラームは、AWS 環境の問題を検知する最初の防衛線です。このブログ記事では、そのギャップを埋める CloudWatch アラームの設計方法を紹介します。適切なものを監視し、必要なコンテキストを含み、適切な対応をトリガーするアラームです。

適切なデータ – 重要なリソースとメトリクスを監視するようにアラームのスコープを設定し、環境の変化に自動的に適応させ、実際の問題を反映する閾値を設定します。
適切なコンテキスト – 通知に必要な情報を含めます。何が影響を受けているか、どこか、どう対処するか。
適切なアクション – 「メールを送る」を超えて、自動修復、情報を付加した通知、複数ツールが連動し一体化されたインシデント対応へ。

前提条件

この記事に沿って進めるには以下が必要です：

Amazon CloudWatch にアクセスできる AWS アカウント
監視対象の既存 AWS リソース（Amazon EC2 インスタンス、AWS Lambda 関数、Application Load Balancer など）
CloudWatch アラーム、メトリクス、ダッシュボードを作成・管理する権限
（オプション）タグベースのフィルタリング用に AWS リソースに適用されたリソースタグ

注意：CloudWatch アラーム、ダッシュボード、Amazon EventBridge には AWS 料金が発生します。詳細は Amazon CloudWatch の料金を参照してください。継続的な課金を避けるため、使い終わったらこれらのリソースを削除してください。

適切なデータ：アラームの対象を重要なものに絞る

次のケースを考えてみましょう。特定の Amazon EC2 インスタンスの CPUUtilization メトリクスに CloudWatch アラームを作成します。問題なく動作します。しかし Amazon EC2 Auto Scaling グループが新しくインスタンスを3台起動すると、新しいインスタンスにはアラームカバレッジがない状態となってしまいます。フリートの75%について監視が欠落した状態です。

あるいは、動的なリソースがあるため、Application Load Balancer の全ターゲットの平均レイテンシメトリクスにアラームを作成します。平均は問題なく見えますが、1つのターゲットは5秒のレスポンスを返し、他は50ミリ秒です。平均が問題を隠してしまいます。

単一メトリクスおよび単一集計値に対するアラームは作成・管理が簡単ですが、単一メトリクスに対するアラームは動的な環境でギャップを残し、単一集計値に対するアラームでは平均値により問題が埋もれてしまいます。

動的リソースへの対応

CloudWatch Metrics Insights を使うと、SQL ライクなクエリを書いて、リソース全体のメトリクスを動的に検出・集計できます。インスタンスごとに1つのアラームを作成する代わりに、環境の変化に自動的に適応するクエリで複数リソースにまたがる単一のアラームを作成します：

SELECT AVG(CPUUtilization)
FROM SCHEMA("AWS/EC2", InstanceId)

この Metrics Insights クエリは全ての EC2 インスタンスを自動的にカバーし、手動更新は不要です。EC2 Auto Scaling グループが3台から30台にスケールしても、アラームは適応します。30個の個別アラームを作成・管理する代わりに、1つのアラームだけを管理すれば済みます。

サーバーレスワークロードの場合、AWS Lambda 関数全体の Duration に対する Metrics Insights クエリを作成することもできます：

SELECT AVG(Duration)
FROM SCHEMA("AWS/Lambda", FunctionName)

コンセプトは同じです。このクエリは Lambda 関数が3個でも30個でもカバーします。

この記事の例では Metrics Insights を使用していますが、PromQL を使ってメトリクスをクエリし、クエリにラベルを含めて同じ効果を得ることもできます。

適切なリソースへの絞り込み

アラームが動的なリソースに適応するようになりましたが、おそらく特定のアプリケーションや環境をターゲットにしたいはずです。InstanceId のような生のディメンション値では、リソースが何をしているか、どれくらい重要かは分かりません。

カスタムメトリクスの場合、ディメンションを自分で制御できます。Application や Environment などのコンテキストを含め、直接クエリします：

SELECT AVG(ProcessingTime)
FROM SCHEMA("Custom/PaymentService", Application, Environment)
WHERE Application = 'PaymentService'
  AND Environment = 'Production'

Amazon EC2 や AWS Lambda などの AWS サービスは、事前定義されたディメンション（例：InstanceId、FunctionName）でベンダーメトリクスを自動的に発行します。独自の追加ディメンションを追加することはできません。代わりに、テレメトリ用のリソースタグでビジネスコンテキストを追加します。

テレメトリでリソースタグを有効にすると、Amazon CloudWatch は既存のリソースタグを Metrics Insights のディメンションとして公開します。リソースに既に適用されているタグ（例：Amazon EC2 インスタンスの Environment=Production や Application=PaymentService）は、WHERE 句や GROUP BY 句で使用可能になります。

SELECT AVG(CPUUtilization)
FROM SCHEMA("AWS/EC2", InstanceId)
WHERE tag.Environment = 'Production'
  AND tag.Application = 'PaymentService'

これで、アラームは PaymentService アプリケーションに属する本番インスタンスを監視します。それらのタグを持つ新しいインスタンスが起動すると、自動的にアラームに含まれます。死角は生まれず、午前2時に開発環境でアラームが鳴ることもありません。

1つのアラーム、複数のリソース

アラームは動的に適応し、適切なリソースをターゲットにするようになりました。しかし、もう1つの問題である問題が平均に埋もれてしまう件を思い出してください。ここで GROUP BY の出番です。クエリに GROUP BY を追加すると、マルチ時系列アラームを作成できます。Amazon CloudWatch はクエリ結果の各時系列に対して独立に閾値を評価します。いずれかの時系列が閾値を超えると、フリート平均が正常に見えてもアラームが発火します。

SELECT AVG(CPUUtilization)
FROM SCHEMA("AWS/EC2", InstanceId)
WHERE tag.Environment = 'Production'
  AND tag.Application = 'PaymentService'
GROUP BY InstanceId

GROUP BY を使うと、グラフには複数の時系列（マッチする EC2 インスタンスごとに1つ）が表示されます。これがなければ、単一の集計ラインだけが表示されます。アラーム用のクエリを確認するには、「メトリクスと条件の指定」ステップのグラフで、1つの集計ではなく複数の時系列を評価していることを確認してください。クエリの下にある「Order By」オプションに注意してください。マルチ時系列アラームには必須です。

Metrics Insights を使ったアラーム作成
図1：Metrics Insights クエリが複数のメトリクス時系列を返すアラーム作成画面。

適切なリソースを監視し、それぞれを独立に評価しています。では、どの値でアラームを発火させるべきでしょうか？

適切な閾値を選ぶ

閾値は「適切なデータ」の最後のピースです。実際の問題をキャッチするアラームと、頻繁に発火しすぎたり、顧客が影響を受けている間も沈黙したままのアラームとの違いを生みます。

静的閾値のアラームは、ハードリミットのあるメトリクスに適しています。ディスク使用率が100%に近づく、キュー深度が際限なく増大する、常にゼロであるべきエラーカウントなどです。「悪い」値が分かっていれば、設定すればそれで完了です。

しかし、多くのメトリクスには自然な変動があります。ピーク時の CPU 使用率70%は正常かもしれませんが、午前2時の同じ70%は懸念材料です。月曜日に200ミリ秒で正常なレイテンシが、静かな日曜日には異常に高いかもしれません。これらの場合、静的閾値は「敏感すぎる（アラート疲れ）」か「寛容すぎる（インシデント見逃し）」のどちらかを選ぶことを強います。

異常検出はこの問題を解決します。Amazon CloudWatch はメトリクスのベースラインパターン（日次・週次のトレンドと期待される範囲）を学習し、その学習プロファイルからメトリクスが逸脱したときにアラームを出します。数値ではなく感度を設定します。「閾値をいくつにすべきか分からない」シナリオや、「正常」が時間とともに変化するメトリクスに最適です。異常検出の仕組みの詳細は「CloudWatch 異常検出の使用」を参照してください。

適切なコンテキスト：通知をアクション可能にする

「何かがおかしい」と「何をすべきか分かっている」のギャップを思い出してください。コンテキストがそれを埋めます。通知が伝える情報が多いほど、対応は速くなります。十分なコンテキストがあれば、対応を完全に自動化できます。

アラームの種類に関係なく、通知には常にアラーム名と説明、状態変更、変更理由、閾値が含まれます。このうち、名前と説明は完全にコントロールできる2つの要素であり、対応者が最初に見るものです。適切に書かれた名前と説明は多くのコンテキストを伝えることができます。アラーム名は素早いシグナルを与えます：本番、決済、CPU。説明にはドキュメント、ランブック、ダッシュボード、エスカレーションパスへのリンクを記載します。

Alarm Details:
- Name:          prod-payments-cpu
- Description:   Alarm on payments service CPU.
                 Impact: Payment processing may slow.
                 Runbook: https://wiki.example.com/runbooks/payment-cpu
                 Dashboard: https://console.aws.amazon.com/cloudwatch/...
                 Escalation: #payments-oncall
- State Change:  OK -> ALARM
- Reason for State Change:    Threshold Crossed: 1 out of the last 1 datapoints [3.0705 (15/06/26 12:49:00)] was more than the threshold (90.0) (minimum 1 datapoint for OK -> ALARM transition).
- Timestamp:     Monday 15 June, 2026 12:54:30 UTC
- AWS Account:   xxxxxxxxxxxx
- Alarm Arn:     arn:aws:cloudwatch:us-east-xxxxxxxxxxxx:alarm:prod-payments-cpu

ダッシュボード：問題の全体像を見せる

アラームは単一の時点で発火します。値は分かりますが、どれくらい速く変化しているか、より広い影響は分かりません。ダッシュボードはより大きな絵を見せることができます。メトリクスの時間的な挙動（スパイクか、徐々に劣化しているか？いつ変化し始めたか？）に加え、そのアラームが発火したときに関連する情報の表示、つまりアプリケーションの RED メトリクス（Requests、Errors、Duration）と関連リソースです。対応者が簡単にアクセスできるよう、アラームの説明にダッシュボード URL を含めてください。

メトリクスクエリからコンテキストを得る

名前と説明は自分で追加するコンテキストであり、全てのアラームタイプの通知イベントにはアラーム詳細が含まれます。しかし、アラーム通知は自動的にコンテキストも運びます。何が含まれるかはアラームの構築方法に依存します。

単一メトリクスアラーム：メトリクス名前空間、名前、ディメンション、統計、メトリクス値。
マルチ時系列アラーム（GROUP BY 付き Metrics Insights）：Metrics Insights クエリ、およびどの時系列が閾値を超えたかを特定する Contributor Attributes。

単一メトリクスアラーム通知は、どのメトリクスが閾値を超えたかを伝えます：

Monitored Metric:
- MetricNamespace:    AWS/EC2
- MetricName:         CPUUtilization
- Dimensions:         [InstanceId = i-xxxxxxxxxxxxxxxxx]
- Statistic:          Average

例えば、Amazon EC2 CPUUtilization のアラームは InstanceId ディメンションを表示し、Lambda Duration のアラームは FunctionName を表示します。ここで表示される内容は、アラーム作成時に選択したメトリクスとディメンションに依存します。

Metrics Insights クエリで作成されたアラームでは、特定のインスタンスの情報を得る唯一の方法は、クエリで GROUP BY 句を使用することです。通知には Contributor Attributes セクションが含まれ、クエリのどの時系列が閾値を超えたかを正確に示します：

Contributor Attributes:
- InstanceId            i-xxxxxxxxxxxxxxxxx
- tag."Environment"     Production
- tag."Application"     PaymentService
Threshold:
- The alarm is in the ALARM state when the metric is GreaterThanThreshold 90.0 for at least 1 of the last 1 period(s) of 300 seconds.
Monitored Metrics:
- MetricExpression:  SELECT AVG(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId) GROUP BY InstanceId, tag.Environment, tag.Application ORDER BY AVG() DESC

GROUP BY に InstanceId、tag.Environment、tag.Application を含めたため、Contributor Attributes は3つの値全てを表示します。これが「あるインスタンスが高負荷」と「本番環境の決済アプリに問題がある」の違いです。

複合アラームによる影響レベルのシグナル化

個々のアラームは個々の症状を伝えます。複合アラームは複数の症状を単一のヘルスシグナルに要約します。

複合アラームは、ブール論理を使って複数の子アラームの状態を組み合わせます。例えば、エラーレートアラームとレイテンシアラームの両方が ALARM 状態のときのみ発火する複合アラームは、エンジニアに2つの別々のアラームではなく影響レベルのシグナル（「サービスが劣化している」）を与えます。

複合アラームはノイズも削減します。10個の子アラームがあり、3個以上が同時に発火しているときだけページしたい場合、複合アラームがそのロジックを処理します。

適切なアクション：通知から解決へ

アラームが発火しました。適切なリソースにスコープを合わせ（適切なデータ）、通知は何が影響を受けているかを伝えます（適切なコンテキスト）。そのコンテキスト（アプリケーション、環境、特定のリソース）があるため、通知以上のことができます。自動化できます。

多くの場合、アラームアクションは「誰かにメールが届く」です。しかし、問いかける価値のある質問があります：このアラームが発火したとき、実際に何が起こるべきでしょうか？

アクションを自動化する

一部のアラームは人間が調査、判断、調整する必要があります。これらには、GROUP BY、タグ、ディメンションを使い、迅速な対応に十分なコンテキストを通知に含めてください。

しかし、対応が決定論的な場合（タスクの再起動、フリートのスケール、障害インスタンスの復旧など）、アラームをそのアクションに直結します。Amazon CloudWatch は EC2 アクション（停止、再起動、復旧）、Amazon EC2 Auto Scaling ポリシー、または AWS Lambda 関数を呼び出せます。人間の介入は不要です。AWS Well-Architected フレームワークはこれを明示的に述べています。人間が毎回同じ方法で同じランブックに従うなら、それは自動化の候補になります。

複雑な対応を連動させる

Amazon CloudWatch はアラームの状態変更時に Amazon EventBridge にイベントを送信します。Amazon EventBridge を使えば、これらのイベントを複数のターゲットに送信できます。アラームが発火したとき、同時に以下を実行できます：

PagerDuty 経由でオンコールエンジニアにページする
チケット管理ツールでインシデントを作成する
コンテキストを付加した専用 Slack チャンネルに投稿する

単一のアラームイベントが、インシデント管理ワークフロー全体にわたる連携した対応を開始します。

計画メンテナンス中のアクション抑制

新バージョンのデプロイ、ロードテストの実行、インフラの更新中に、アラームが自動修復を呼び出したり、予期された動作でエンジニアにページしたりすることは望ましくありません。

CloudWatch アラームミュートルールを使えば、事前定義された時間ウィンドウ中にアラームアクションを一時的に抑制できます。アラームアクションの無効化（誰かがアラームを再度有効にすることを覚えている必要がある）とは異なり、ミュートルールは特定の時間ウィンドウ用です。アラームは評価と状態変更を続けますが、ミュートウィンドウ中はアクションを呼び出しません。ミュートルールは特定のアラームにスコープできます。デプロイ対象のサービスのアラームをミュートしながら、残りの監視は完全にアクティブのままです。

ミュートルールがなければ、デプロイは不要なアラームノイズを生みます。予期された動作でアラームが発火し、対応者はそれを無視するようになり、アラームシステムへの信頼が損なわれます。

実践的なパターン：CI/CD パイプラインでデプロイ前にミュートルールを作成し、デプロイと安定化の時間をカバーする有効期限ウィンドウを設定します。ウィンドウの期限切れ後にアラームが発火すれば、デプロイノイズではなく実際の問題だと分かります。

全要素の統合

午前2時のアラームに戻りましょう。適切なデータ、適切なコンテキスト、適切なアクションを組み合わせるとこうなります：

アラームは GROUP BY とリソースタグによるフィルタリングを使った Metrics Insights クエリを使用するため、フリート全体を自動的にカバーし、適切な環境とアプリケーションにスコープを合わせます。
通知は特定のインスタンス、環境、アプリケーション名を含み、さらに影響の説明とランブックおよび RED メトリクスを表示するダッシュボードへのリンクを含むアラーム説明があります。
アラームアクションは既知の問題に対する自動復旧を呼び出します。復旧に失敗した場合、または自動化できない場合、コンテキストを付加してインシデント管理プロセスにエスカレーションします。

午前2時にアラームが発火します。インスタンスは自動復旧されます。アラームは OK に戻ります。誰もページされません。

まとめ

CloudWatch アラームは、適切なリソースを監視し、必要なコンテキストを含み、適切な対応をトリガーするときに最も効果的です。GROUP BY 付き Metrics Insights クエリを使用し、タグと説明で通知を充実させ、可能な場合は対応を自動化することで、アラームをノイズからアクション可能なシグナルに変えることができます。

さっそく始めましょう

実践的なスタートパスを示します：

主要サービスの Amazon CloudWatch 設定でテレメトリでリソースタグを有効にします。
既存リソースの AWS 推奨アラームをレビューします。
最も価値の高い静的アラームを GROUP BY とタグベースのスコープ付き Metrics Insights クエリに変換します。
明確な静的閾値がないメトリクスに異常検出を追加します。
有用なリンク付きの意味のあるアラーム説明を書きます。
重要なサービスのダッシュボードを作成し、アラーム説明にリンクします。
デプロイウィンドウと計画メンテナンス用のアラームミュートルールを設定します。
重要なサービスの複合アラームを作成します。個々の症状ではなく影響レベルのシグナルを表面化させます。
既知の解決策に対して自動アクションを実装します。人間の判断が必要な問題のために、人間の注意力を温存します。

全てを一度にやる必要はありません。1つのサービスから始め、パターンを正しく構築し、そこから拡張してください。午前2時のあなたが感謝するはずです。

クリーンアップ

CloudWatch アラーム、ダッシュボード、EventBridge ルールには AWS 料金が発生します。詳細は Amazon CloudWatch の料金を参照してください。継続的な課金を避けるため、使い終わったらこれらのリソースを削除してください。

Amazon Web Services ブログ