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の使用が推奨されています。