AWS EventBridge入門｜イベント駆動アーキテクチャの設計とLambda連携の実践
EventBridgeとは？サーバーレス自動化の要となるイベントバス
私が日々のAWS運用でよく使うサービスのひとつが、Amazon EventBridgeです。X（Twitter）への自動投稿ボットやDynamoDBとLambdaを組み合わせた自動化処理など、実際の業務でEventBridgeを活用してきた経験をもとに解説します。
EventBridgeはAWSのマネージドイベントバスサービスです。「何かが起きたら（イベント）、これを実行する（ターゲット）」という仕組みをサーバーレスで実現できます。EC2サーバーを立てる必要がなく、コストも低く抑えられます。
EventBridgeの3つの主要コンポーネント
1. イベントバス
イベントが流れる「パイプ」のようなものです。デフォルトバス（AWSサービスのイベントが流れる）とカスタムバス（自前のアプリからのイベント）の2種類があります。
2. ルール
「どのイベントに反応するか」を定義します。イベントパターンマッチング（特定の条件に合うイベントのみ）またはスケジュール（cron式・rate式）で設定できます。
3. ターゲット
イベントが来たときに実行する処理先です。Lambda関数・SQS・SNS・ECS・Step Functionsなど20以上のAWSサービスをターゲットに指定できます。
実践：Lambda関数を定期実行する
最もよく使うパターンが「定期実行（スケジューラ）」です。私のX投稿ボットもこのパターンで動いています。
設定の流れは以下のとおりです：
- EventBridgeコンソールで「ルールを作成」を選択
- 「スケジュール」を選択し、rate式（例：rate(30 minutes)）またはcron式を設定
- ターゲットとして呼び出したいLambda関数を指定
- IAMロールを設定してEventBridgeにLambda実行権限を付与
rate(30 minutes)と設定すれば30分ごとにLambdaが自動実行されます。CloudWatch Eventsの後継サービスなので、既存のCloudWatch EventsルールはそのままEventBridgeで管理できます。
実践：AWSサービスのイベントをトリガーにする
もうひとつの代表的な使い方が「AWSサービスのイベント検知」です。たとえばEC2インスタンスの状態変化（起動・停止）を検知してLambdaで通知を飛ばす、S3にファイルがアップロードされたら処理を開始するといったパターンです。
イベントパターンの例（EC2インスタンス停止を検知）：
- source: aws.ec2
- detail-type: EC2 Instance State-change Notification
- detail.state: stopped
実際の現場では、このパターンを使って「本番EC2が予期せず停止したらSlackに通知する」仕組みを構築することがよくあります。
EventBridgeとSQS・SNSの使い分け
「EventBridge、SQS、SNSの違いがわからない」という質問をよく受けます。大まかな使い分けの基準はこうです：
- EventBridge：AWSサービス間のイベント連携・定期スケジュール実行に最適
- SNS：複数の宛先に同時通知（pub/subモデル）したい場合
- SQS：キューに溜めて非同期処理・リトライが必要な場合
これらを組み合わせることでより堅牢な自動化アーキテクチャが実現できます。
まとめ：EventBridgeは運用自動化の出発点
Amazon EventBridgeは、定期実行からイベント駆動アーキテクチャまで幅広く活用できるサービスです。Lambdaと組み合わせることでサーバーレスな自動化基盤が手軽に構築できます。まずはシンプルなスケジュール実行から始めてみてください。
EventBridgeのスケジュール機能：cron式とrate式
EventBridgeはcron式またはrate式でLambdaなどを定期実行できます。私がX（Twitter）への自動投稿ボットを構築したときも、この機能を使って毎日決まった時間に投稿を自動実行しました。
# rate式（シンプルな繰り返し）
rate(5 minutes) # 5分ごと
rate(1 hour) # 1時間ごと
rate(1 day) # 1日ごと
# cron式（細かい制御）
cron(0 9 * * ? *) # 毎日9時（UTC）
cron(0 0 1 * ? *) # 毎月1日の0時（UTC）
cron(0 12 ? * MON-FRI *) # 平日12時（UTC）
注意：EventBridgeのcron式はUTC基準です。日本時間（JST）は+9時間のため、日本時間9時に実行したい場合はcron(0 0 * * ? *)と設定します。
EventBridgeのイベントパターンマッチング
AWSサービスのイベント（EC2インスタンスの状態変化・S3へのオブジェクトアップロード・CodePipelineのステータス変化など）をトリガーにしてターゲットを実行できます。
EC2インスタンスが停止したときにLambdaを実行する例：
{
"source": ["aws.ec2"],
"detail-type": ["EC2 Instance State-change Notification"],
"detail": {
"state": ["stopped"]
}
}
このパターンにマッチしたイベントが発生すると、設定したターゲット（Lambda・SNS・SQS・Step Functionsなど）が自動実行されます。
EventBridgeの主なターゲット
- Lambda：最も使われる組み合わせ。イベント内容をeventオブジェクトとして受け取れる
- SQS：処理を非同期にしたい場合。Lambdaが直接処理する前にキューに蓄積できる
- SNS：通知配信に使う。EventBridge → SNS → メール/Slack/SMSという通知フローが定番
- Step Functions：複数のLambdaを連携した複雑なワークフローを実行したい場合
- ECS Task：バッチ処理や定期レポート生成など、コンテナで処理を実行したい場合
EventBridgeとCloudWatch Eventsの違い
旧来のCloudWatch EventsがEventBridgeに進化したサービスです。機能的にはEventBridgeの方が上位で、サードパーティSaaSのイベント受信やカスタムバスによるマイクロサービス間連携など、CloudWatch Eventsにはなかった機能が追加されています。現在はEventBridgeの使用が推奨されています。
まとめ：EventBridgeを活用した自動化のパターン
- 定期実行：cron/rate式でLambdaをスケジュール実行（バッチ処理・定期通知）
- イベント駆動：AWSサービスのイベントをトリガーに自動処理（EC2停止の自動通知・S3アップロードの変換処理）
- マイクロサービス連携：カスタムバスでサービス間のイベント連携を疎結合に実現
EventBridgeはAWSサーバーレスアーキテクチャの「神経系」と言える存在です。LambdaやSNS・SQSと組み合わせることで、サーバーレス自動化の幅が大きく広がります。まずスケジュール実行から試してみることをおすすめします。
