【AWS運用・監視】CloudWatch・EventBridge・Lambdaの実務での使い方と構成パターン完全ガイド

AWSで本番環境を運用していると、「何かが起きたときにすぐ気づけるか」「問題を自動で修復できるか」が運用品質を大きく左右します。

この記事では、AWS運用・監視の中核を担うCloudWatch・EventBridge・Lambdaの役割と、実務でよく使われる構成パターンを解説します。

---

運用・監視の基本的な考え方

AWSの運用・監視は大きく3つのフェーズに分かれます。

① 検知　→　何かが起きたことを気づく
② 通知　→　担当者や外部システムに伝える
③ 対応　→　手動または自動で修復する

この3つのフェーズを担うのが、CloudWatch・EventBridge・Lambdaです。それぞれの役割を整理すると以下のようになります。

サービス	主な役割
CloudWatch	検知（メトリクス監視・ログ収集・アラーム）
EventBridge	橋渡し（イベントをルーティングする）
Lambda	対応（自動修復・自動処理を実行する）
SNS	通知（人や外部システムに伝える）

---

CloudWatchの実務での使い方

メトリクス監視

CloudWatchはAWSリソースのメトリクスを自動収集します。EC2のCPU使用率、RDSの接続数、ALBのリクエスト数など、主要なメトリクスはデフォルトで収集されます。

実務でよく監視するメトリクスは以下のとおりです。

EC2

RDS

ALB

CloudWatchアラームの設定

メトリクスがしきい値を超えたときにアラームを発火させます。実務では以下の3つの状態を意識して設定します。

OK　　　→　正常範囲内
ALARM　→　しきい値を超えた（異常）
INSUFFICIENT_DATA　→　データ不足

アラームの設定で重要なのが評価期間です。1回の測定でアラームを発火させると誤検知が多くなるため、「5分間隔で3回連続してしきい値を超えたらアラーム」のように複数回の条件を設定するのが実務では一般的です。

CloudWatch Logsの活用

アプリケーションログやAWSサービスのログをCloudWatch Logsに集約することで、一元的に管理できます。

実務でよく使うログの種類：

ログインサイトを使えば、大量のログに対してSQLライクなクエリを実行して素早く原因を特定できます。障害対応時に「直近1時間でエラーが何件発生したか」をすぐに調べられるのは非常に実用的です。

---

EventBridgeの実務での使い方

EventBridgeは「イベントを受け取って、どこかに送る」サービスです。以前はCloudWatch Eventsという名前でしたが、現在はEventBridgeに統合されています。

イベントソースの種類

EventBridgeが受け取れるイベントは大きく3種類あります。

AWSサービスのイベント（デフォルトで飛んでくる）

これらはAWSが自動的にEventBridgeにイベントを送信してくれます。わざわざカスタムの仕組みを作る必要がないので、実務では「まずEventBridgeで対応できないか」を確認するのが効率的です。

スケジュールイベント

cron式またはrate式でイベントを定期的に発生させます。

rate(5 minutes)　→　5分ごとに実行
rate(1 day)　　　→　毎日実行
cron(0 9 * * ? *)　→　毎日午前9時に実行

定期的なバックアップ、レポート生成、古いリソースの自動削除などに活用されます。

カスタムイベント

アプリケーションから独自のイベントをEventBridgeに送ることもできます。マイクロサービス間の疎結合な連携に活用されます。

ルールとターゲット

EventBridgeはイベントを受け取ると、設定したルールに基づいてターゲットに送信します。

主なターゲット：

---

Lambdaの実務での使い方

Lambdaは「コードをサーバーなしで実行できる」サービスです。運用・監視の文脈では、自動対応・自動修復の役割を担います。

運用自動化の典型パターン

パターン1：リソースの自動タグ付け

新しいEC2インスタンスが起動したとき、自動的にタグを付与します。

EC2起動（EventBridge検知）
　↓
Lambda実行
　↓
EC2に作成者・部署・環境などのタグを自動付与

パターン2：コスト最適化の自動化

業務時間外に開発環境のEC2を自動停止します。

EventBridge（毎日19時にスケジュール）
　↓
Lambda実行
　↓
「development」タグが付いたEC2を自動停止

パターン3：セキュリティの自動修復

S3バケットのパブリックアクセスが有効になったら自動的に無効化します。

AWS Config（設定変更を検知）
　↓
EventBridge
　↓
Lambda実行
　↓
S3バケットのパブリックアクセスを自動ブロック

パターン4：障害の自動復旧

EC2のステータスチェックが失敗したら自動的に再起動します。

CloudWatchアラーム（StatusCheckFailed検知）
　↓
EC2 Auto Recovery（または Lambda）
　↓
インスタンスの自動再起動

Lambdaの実務での注意点

タイムアウト設定

Lambdaのデフォルトタイムアウトは3秒です。処理が長くなる場合は必ず延長しておきます。最大15分まで設定可能ですが、長時間の処理はStep Functionsに切り出すことを検討します。

エラーハンドリング

Lambdaが失敗した場合の動作を必ず設計します。デッドレターキュー（DLQ）にSQSやSNSを設定しておくと、失敗したイベントを後から確認・再処理できます。

冪等性（べきとうせい）の確保

同じイベントが複数回届いても同じ結果になるように実装します。Lambdaは稀に同じイベントを複数回実行することがあるため、処理が重複しても問題ない設計にしておくことが重要です。

---

実務でよく使う構成パターン

パターン1：標準的な監視・通知構成

CloudWatchアラーム
　↓
SNSトピック
　↓
メール通知 / Slackへのwebhook / チケットツール

最もシンプルで基本的な構成です。CloudWatchアラームがSNSを直接呼び出せるため、Lambdaが不要でシンプルに実装できます。

パターン2：自動修復構成

CloudWatchアラーム or AWS Config
　↓
EventBridge
　↓
Lambda（自動修復処理）
　↓
SNS（修復完了通知）

異常を検知したら自動で修復し、完了したら通知する構成です。深夜の障害対応を自動化するのに有効です。

パターン3：定期バッチ処理構成

EventBridge（cronスケジュール）
　↓
Lambda（バッチ処理）
　↓
結果をDynamoDBやS3に保存
　↓
CloudWatch Logsに実行ログ出力

定期的なレポート生成やデータ集計に使われます。EC2やサーバーを立てずにサーバーレスで実現できるのがポイントです。

パターン4：マルチアカウント監視構成

各アカウントのCloudWatch
　↓
EventBridge（クロスアカウント転送）
　↓
中央監視アカウントのEventBridge
　↓
Lambda / SNS（一元通知）

Organizations配下の複数アカウントを一元管理する場合に使われます。各アカウントのイベントを中央アカウントに集約することで、監視の漏れを防ぎます。

---

CloudWatch・EventBridge・Lambdaの使い分けまとめ

やりたいこと	使うサービス
メトリクスを監視してアラートを出したい	CloudWatchアラーム
ログを収集・分析したい	CloudWatch Logs
AWSサービスのイベントを検知したい	EventBridge
定期的にバッチ処理を実行したい	EventBridge + Lambda
異常を検知して自動修復したい	CloudWatch/Config + EventBridge + Lambda
人に通知したい	SNS
処理をキューイングしたい	SQS

---

まとめ

AWSの運用・監視は「検知→通知→対応」の3フェーズを意識することが重要です。

CloudWatchで異常を検知し、EventBridgeでイベントをルーティングし、Lambdaで自動対応する。この流れを押さえておけば、ほとんどの運用自動化シナリオに対応できます。

最初からすべてを自動化しようとするのではなく、まず手動対応しているオペレーションを洗い出し、繰り返し発生するものから順番に自動化していくのが実務での現実的なアプローチです。

運用の品質は「いかに人間が介在しなくてもシステムが自律的に動くか」で決まります。CloudWatch・EventBridge・Lambdaを組み合わせることで、その理想に近づけることができます。