「CloudWatchでメトリクスは見ているのに、障害が起きても通知が来ない」
AWSの監視設定は「とりあえず入れた」状態のままになりがちです。メトリクスを眺めるだけの監視と、障害をリアルタイムで検知して担当者に通知できる監視では、本番運用の安心感がまったく違います。
この記事では、Amazon EventBridgeとAmazon SNSを組み合わせたAWS監視の通知フロー設計を解説します。CloudWatchアラームによるリソース監視から、EventBridgeルールを使ったAWSサービスのイベント検知、SNSによるメール・Slack通知の接続まで、設計の全体像をステップで説明します。想定環境はAWS(東京リージョン)です。
この記事のポイント
・CloudWatch→SNS→メール通知が「aws監視」の最短パス
・EventBridgeはサービスイベント(EC2停止・RDS障害等)の検知に使う
・SNSトピックを中継点にすると通知先を後から追加しやすい
・通知が届かない原因の9割はサブスクリプション未確認かIAMポリシー不足
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
AWSの監視設計で押さえるべき3層構造
AWSの監視通知は、以下の3つのサービスが役割を分担する構造で設計します。・Amazon CloudWatch:CPU使用率・ディスク・ネットワーク等のメトリクスを収集し、しきい値を超えたらアラームを発火する
・Amazon EventBridge:AWSサービスが発するイベント(EC2の状態変化、RDSのフェイルオーバー、Security Hubの検出等)をルールでフィルタリングし、ターゲットへ転送する
・Amazon SNS(Simple Notification Service):メール・SMS・HTTPSエンドポイント・Lambdaなど複数の宛先に同時通知する中継点。CloudWatchとEventBridge両方のアラート先として機能する
この3層を正しく接続することで、「リソースの異常」と「AWSサービスのイベント」の両方を一元的に検知し、担当者へ通知できます。
CloudWatchアラームとSNSで通知を受け取る基本設定
1. SNSトピックを作成する
まずすべての通知の受け口となるSNSトピックを作成します。AWS CLIで行う場合は以下のとおりです。# SNSトピックを作成する(標準タイプ) aws sns create-topic \ --name prod-alert-topic \ --region ap-northeast-1 # 出力例(環境により異なります) # { # "TopicArn": "arn:aws:sns:ap-northeast-1:123456789012:prod-alert-topic" # }
# メールアドレスをSNSトピックにサブスクライブ aws sns subscribe \ --topic-arn arn:aws:sns:ap-northeast-1:123456789012:prod-alert-topic \ --protocol email \ --notification-endpoint admin@example.com \ --region ap-northeast-1
2. CloudWatchアラームを作成しSNSに連携する
EC2のCPU使用率が5分間80%を超えたらSNSに通知するアラームを設定します。# EC2 CPU使用率80%超えでSNS通知するアラームを作成 aws cloudwatch put-metric-alarm \ --alarm-name "prod-ec2-cpu-high" \ --alarm-description "CPU usage over 80% for 5 minutes" \ --metric-name CPUUtilization \ --namespace AWS/EC2 \ --statistic Average \ --period 300 \ --threshold 80 \ --comparison-operator GreaterThanThreshold \ --evaluation-periods 1 \ --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \ --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:prod-alert-topic \ --ok-actions arn:aws:sns:ap-northeast-1:123456789012:prod-alert-topic \ --region ap-northeast-1
3. アラームの状態を確認する
# アラームの現在状態を確認 aws cloudwatch describe-alarms \ --alarm-names "prod-ec2-cpu-high" \ --region ap-northeast-1 # 出力例(抜粋・環境により異なります) # "StateValue": "OK", # "StateReason": "Threshold Crossed: 1 out of the last 1 ...",
EventBridgeルールでAWSサービスのイベントをリアルタイム検知する
CloudWatchアラームはメトリクスの異常検知に強い一方、「EC2インスタンスが誰かに停止させられた」「RDSがフェイルオーバーした」といったAWSサービス側のイベントは、EventBridgeルールで捕捉します。1. EventBridgeルールをAWS CLIで作成する
EC2インスタンスの状態変化(停止・終了)を検知するルールを作成します。# EventBridgeルールを作成(EC2の状態変化を検知) aws events put-rule \ --name "ec2-state-change-alert" \ --event-pattern '{ "source": ["aws.ec2"], "detail-type": ["EC2 Instance State-change Notification"], "detail": { "state": ["stopped", "terminated"] } }' \ --state ENABLED \ --region ap-northeast-1
2. ルールのターゲットにSNSを設定する
# EventBridgeルールのターゲットにSNSトピックを設定 aws events put-targets \ --rule "ec2-state-change-alert" \ --targets '[ { "Id": "sns-target-1", "Arn": "arn:aws:sns:ap-northeast-1:123456789012:prod-alert-topic" } ]' \ --region ap-northeast-1
実務で使える通知フロー設計パターン
以下の3パターンを環境の重要度に応じて使い分けると、過通知と見落としのバランスが取りやすくなります。| 検知したいこと | 使うサービス | 設計のポイント |
|---|---|---|
| CPU・メモリ・ディスクの高負荷 | CloudWatch Alarm → SNS | evaluation-periodsを2~3にして瞬間値での誤発報を防ぐ |
| EC2停止・RDSフェイルオーバー | EventBridge → SNS | detail.stateで状態を絞り込み、自動スケーリングの正常停止は除外する |
| コスト超過・予算アラート | AWS Budgets → SNS | 月次・週次の予算しきい値で2段階通知(80%・100%)を設定する |
本番AWS環境の構築・設計スキルを体系的に学びたい方には、AWSマスターセミナーの詳細ページで学習ロードマップを公開しています。
トラブルシュート|通知が届かない時の確認手順
1. SNSサブスクリプションが確認済みか確認する
# サブスクリプション一覧を確認 aws sns list-subscriptions-by-topic \ --topic-arn arn:aws:sns:ap-northeast-1:123456789012:prod-alert-topic \ --region ap-northeast-1 # 出力例(抜粋・環境により異なります) # "SubscriptionStatus": "confirmed" ← これが届く条件 # "SubscriptionStatus": "pending confirmation" ← メールのリンクを踏んでいない
2. EventBridgeからSNSへのIAMポリシーを確認する
EventBridgeがSNSにパブリッシュできない場合、CloudTrailのログに `AccessDenied` が記録されます。SNSトピックのアクセスポリシーに以下の許可が含まれているか確認します。# SNSトピックの属性(アクセスポリシー)を取得して確認 aws sns get-topic-attributes \ --topic-arn arn:aws:sns:ap-northeast-1:123456789012:prod-alert-topic \ --region ap-northeast-1 # ポリシー内に以下の記述が必要 # "Principal": {"Service": "events.amazonaws.com"}, # "Action": "sns:Publish"
3. CloudWatchアラームのテスト通知を送る
設定後にテスト通知を手動で発火させて、エンドツーエンドで通知が届くことを確認してください。# アラームを強制的にALARM状態にしてSNS通知をテストする aws cloudwatch set-alarm-state \ --alarm-name "prod-ec2-cpu-high" \ --state-value ALARM \ --state-reason "Manual test" \ --region ap-northeast-1
まとめ
| やりたいこと | 使うサービスと設定 |
|---|---|
| SNS通知先の作成 | aws sns create-topic → aws sns subscribe → メール確認 |
| CPU・メトリクス異常の検知 | aws cloudwatch put-metric-alarm --alarm-actions <SNS ARN> |
| EC2停止などのサービスイベント検知 | aws events put-rule → aws events put-targets |
| 通知が届かない時の確認 | サブスクリプション状態 → SNSリソースポリシー → CloudTrail |
| 設定後のエンドツーエンドテスト | aws cloudwatch set-alarm-state --state-value ALARM |
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:AWS VPC Peeringを活用したマルチAZ構成設計ガイド|CIDR重複回避と経路制御
- この記事の属するカテゴリ:AWS(Amazon Linux)へ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます