本番を守るAWS監視の通知フロー設計|EventBridgeとSNSで障害をリアルタイム検知

運営:リナックスマスター.JP(代表 宮崎智広)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > AWS(Amazon Linux) > 本番を守るAWS監視の通知フロー設計|EventBridgeとSNSで障害をリアルタイム検知
「本番のEC2が止まったのに、誰も気づかなかった」
「CloudWatchでメトリクスは見ているのに、障害が起きても通知が来ない」

AWSの監視設定は「とりあえず入れた」状態のままになりがちです。メトリクスを眺めるだけの監視と、障害をリアルタイムで検知して担当者に通知できる監視では、本番運用の安心感がまったく違います。

この記事では、Amazon EventBridgeとAmazon SNSを組み合わせたAWS監視の通知フロー設計を解説します。CloudWatchアラームによるリソース監視から、EventBridgeルールを使ったAWSサービスのイベント検知、SNSによるメール・Slack通知の接続まで、設計の全体像をステップで説明します。想定環境はAWS(東京リージョン)です。

この記事のポイント

・CloudWatch→SNS→メール通知が「aws監視」の最短パス
・EventBridgeはサービスイベント(EC2停止・RDS障害等)の検知に使う
・SNSトピックを中継点にすると通知先を後から追加しやすい
・通知が届かない原因の9割はサブスクリプション未確認かIAMポリシー不足


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

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

サブスクライブ後、登録したメールアドレスに確認メールが届きます。「Confirm subscription」リンクをクリックしないと通知が届きません。これを見落とすのが最も多いミスです。

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

`--alarm-actions` にSNSトピックのARNを指定することで、アラーム発火時にSNSへ通知が飛びます。`--ok-actions` を設定すると、アラームが解除された際にも通知を受け取れます。

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 ...",

`StateValue` が `OK`・`ALARM`・`INSUFFICIENT_DATA` のどれかを確認します。作成直後は `INSUFFICIENT_DATA` になるのが正常です。

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

EventBridgeがSNSにメッセージを送るには、SNSトピック側のアクセスポリシーでEventBridgeからの `sns:Publish` を許可する必要があります。マネジメントコンソールからターゲットを設定すると自動でポリシーが付与されますが、CLIで設定した場合は手動でリソースポリシーを確認してください。

実務で使える通知フロー設計パターン

以下の3パターンを環境の重要度に応じて使い分けると、過通知と見落としのバランスが取りやすくなります。
検知したいこと 使うサービス 設計のポイント
CPU・メモリ・ディスクの高負荷 CloudWatch Alarm → SNS evaluation-periodsを2~3にして瞬間値での誤発報を防ぐ
EC2停止・RDSフェイルオーバー EventBridge → SNS detail.stateで状態を絞り込み、自動スケーリングの正常停止は除外する
コスト超過・予算アラート AWS Budgets → SNS 月次・週次の予算しきい値で2段階通知(80%・100%)を設定する
SNSトピックを通知先ごとに分ける(例: `prod-critical-topic`・`prod-warning-topic`)と、緊急度別にサブスクライバーを分けられます。深夜帯の軽微なアラームで電話が鳴らないようにする設計のベースになります。

本番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" ← メールのリンクを踏んでいない

`pending confirmation` が残っていると通知は届きません。確認メールを再送する場合は SNS コンソールから再送できます。

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

テスト後は状態が自動でリセットされず `ALARM` のままになるため、実際のメトリクスで自然に `OK` に戻るか、`set-alarm-state --state-value OK` で手動リセットしてください。

まとめ

やりたいこと 使うサービスと設定
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
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、AWSマスターセミナーではEC2・VPC・IAMの設計から監視・自動化まで、少人数ハンズオン形式で指導しています。詳細はこちら>> AWSマスターセミナーの詳細を見る

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録

運営

リナックスマスター.JP(代表 宮崎智広)

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。