AWS環境の運用において、システムの異常を早期に検知し、適切な担当者へ迅速に通知することは、サービスの信頼性を維持するために不可欠です。しかし、アラームの閾値設定や通知ルールの設計が不適切であると、大量の誤検知（アラートノイズ）が発生して運用メンバーが疲弊したり、逆に重大な障害を見落としたりするリスクが生じます。
本記事では、実務でそのまま活用できるCloudWatchアラームの設計基準、Terraformによる実装例、およびアラーム運用のチェックリストを解説します。
対象読者と前提条件
- AWS環境のインフラ構築・運用を担当するエンジニア
- CloudWatchアラームの閾値設定や通知設計に課題を感じている方
- Terraformを使用したInfrastructure as Code (IaC) の基本操作ができる方
1. アラーム設計の判断基準（重要度分類）
すべてのアラームを同じ優先度で通知すると、運用の現場は混乱します。アラームは「即時対応が必要なもの（Critical）」と「営業時間内の確認でよいもの（Warning）」に明確に分類します。
| 重要度 (Severity) | 対象メトリクス例 | 通知先 | 求められるアクション |
|---|---|---|---|
| Critical (即時対応) | ・ALB 5XXエラー急増 ・ECSタスクの全滅 ・RDS接続不能 |
PagerDuty, Slack (専用緊急チャンネル), 電話等 | 24時間365日、即時オンコール対応を開始する。 |
| Warning (要確認) | ・CPU使用率の高止まり (例: 80%以上) ・ディスク容量の逼迫 (例: 残り20%以下) |
Slack (通常通知チャンネル), Backlog/Jiraチケット起票 | 翌営業日、または日中の空き時間に原因調査とリソース拡張を行う。 |
2. Terraformによるアラーム実装例
以下は、Amazon ECS (Fargate) のCPU使用率と、Application Load Balancer (ALB) の5XXエラー率を監視するためのTerraformコード例です。環境に合わせて閾値や評価期間を調整してご利用ください。
# SNS Topic for Critical Alerts
resource "aws_sns_topic" "critical_alerts" {
name = "project-critical-alerts-topic"
}
# 1. ECS CPU Utilization Alarm (Warning)
resource "aws_cloudwatch_metric_alarm" "ecs_cpu_high_warning" {
alarm_name = "ecs-cpu-utilization-high-warning"
comparison_operator = "GreaterThanOrEqualToThreshold"
evaluation_periods = 3
metric_name = "CPUUtilization"
namespace = "AWS/ECS"
period = 60 # 1分間隔
statistic = "Average"
threshold = 80
alarm_description = "ECS Task CPU utilization is high (>= 80%) for 3 consecutive periods."
alarm_actions = [aws_sns_topic.critical_alerts.arn] # 実務ではWarning用のトピックを推奨
dimensions = {
ClusterName = "my-ecs-cluster"
ServiceName = "my-ecs-service"
}
}
# 2. ALB 5XX Error Rate Alarm (Critical)
resource "aws_cloudwatch_metric_alarm" "alb_5xx_high_critical" {
alarm_name = "alb-5xx-error-rate-high-critical"
comparison_operator = "GreaterThanThreshold"
evaluation_periods = 2
metric_name = "HTTPCode_Target_5XX_Count"
namespace = "AWS/ApplicationELB"
period = 60 # 1分間隔
statistic = "Sum"
threshold = 10 # 1分間に10件以上の5XXエラーが発生した場合
alarm_description = "ALB target 5XX error count exceeded 10 for 2 consecutive periods."
alarm_actions = [aws_sns_topic.critical_alerts.arn]
dimensions = {
LoadBalancer = "app/my-load-balancer/50dc6c495c0c9188"
}
}
※注意: LoadBalancer ディメンションに指定する値は、実際のARNの app/ 以降の部分を指定する必要があります。ご利用の環境に合わせて書き換えてください。
3. 誤検知を防ぐための設定テクニック
評価期間（Evaluation Periods）とデータポイント（Datapoints to Alarm）の調整
一時的なスパイク（一瞬のCPU負荷上昇など）でアラームが鳴るのを防ぐため、評価期間を適切に設定します。
-
悪い例:
period = 60(1分),evaluation_periods = 1でCPU 90%以上を検知。- 一瞬のバッチ処理やデプロイ時の負荷でアラームが作動し、誤検知の原因になります。
-
良い例:
period = 60(1分),evaluation_periods = 3（3回連続）、またはdatapoints_to_alarm = 2（3回中2回）で検知。- 継続的な異常状態のみをフィルタリングできます。
欠落データの処理 (Missing Data Treatment)
メトリクスが送信されない期間の扱いを明示的に設定します。デフォルト設定のままにすると、データが途切れた際にアラーム状態が「INSUFFICIENT_DATA」となり、意図しない通知やアラームの不発が発生します。
-
missing_data_value_treatmentオプションの選定基準:- notBreaching: データがない場合は「正常」とみなす（例: エラー件数メトリクス。エラーがない時はデータが送られないため）。
- breaching: データがない場合は「異常」とみなす（例: 死活監視、定期実行バッチのハートビート）。
- ignore: 現在の状態を維持する。
4. 実務用アラーム設計チェックリスト
本番環境にアラームを導入する前に、以下のチェックリストを用いて設定内容をレビューしてください。
- 通知先は適切か: Criticalアラームが個人のメールアドレスではなく、共有の連絡先やオンコールツール（PagerDuty等）に紐づいているか。
- 自動復旧時の通知: アラームが「OK」状態に戻った際の通知（Auto-Resolve）が必要か検討されているか（不要な復旧通知はノイズになるため、Warningレベルでは無効化を推奨）。
- 説明欄（Description）の充実: アラーム発生時に、受信者が何をすべきか（RunbookのURL、確認すべきダッシュボード、担当チーム）が記載されているか。
- メンテナンス時間の考慮: 定期バッチやバックアップなど、計画された高負荷時間帯にアラームを一時停止する仕組み（CloudWatchのアラームアクション無効化や、EventBridgeによるスケジュール制御）があるか。
5. 導入時の注意点と運用上の判断基準
閾値の定期的な見直し
システムの成長やアクセスパターンの変化に伴い、適切な閾値は変化します。最低でも四半期に一度は、過去のメトリクス推移をCloudWatchダッシュボードで確認し、閾値が実態に即しているか見直す運用フローを構築してください。
最新の公式ドキュメントの確認
CloudWatchの仕様やサポートされるメトリクス、TerraformのAWSプロバイダーの構文は変更される可能性があります。実際に構築を行う際は、必ず最新のAWS公式ドキュメントおよびTerraform Registryの情報を確認してください。
まとめ
CloudWatchアラームは、ただ設定するだけでは運用の負荷を増やす原因になり得ます。重要度に応じた通知先の切り分け、評価期間の適切な設定、そして欠落データの処理を正しく設計することで、本当に対応が必要な異常だけを早期に検知できる体制を整えましょう。