サーバーレス

Amazon EventBridge あまぞんいべんとぶりっじ

イベント駆動アーキテクチャサーバーレスAWSイベントバスルーティングSaaS連携

EventBridgeについて教えて

簡単に言うとこんな感じ！

EventBridgeは、AWSのサービス同士やSaaSツールを「何かが起きたら次のアクションを自動で実行」ってつなぐ”電話交換手”みたいなものだよ！「注文が入ったら在庫を更新して、メールも送って」みたいな連携を、コード最小限で組み立てられるんだ！

Amazon EventBridgeとは

Amazon EventBridge（イベントブリッジ）は、AWSが提供するサーバーレスのイベントバスサービスです。「イベント」とは「何かが起きた」という通知のことで、たとえば「EC2インスタンスが停止した」「S3にファイルがアップロードされた」「Salesforceで商談が更新された」といった出来事がイベントにあたります。EventBridgeはこれらのイベントを受け取り、あらかじめ定義したルールに従って適切な宛先（Lambda関数・SQS・Step Functionsなど）へ自動的に振り分けます。

イベント駆動アーキテクチャ（Event-Driven Architecture：何かが起きたことをトリガーにして処理を連鎖させる設計）の中心的な役割を担うのがEventBridgeです。従来はシステム間の連携にAPIの直接呼び出しや複雑なバッチ処理が必要でしたが、EventBridgeを使うと送り手と受け手を疎結合（お互いを直接知らなくてよい状態）に保ちながら柔軟に連携できます。

もともとは「CloudWatch Events」という名称でAWSサービス内のイベント通知のみを扱っていましたが、2019年にEventBridgeとして独立・強化され、SaaSサービスとの直接統合やカスタムイベントバスなど、エンタープライズ向けの機能が大幅に拡充されました。

EventBridgeの主要コンポーネント

コンポーネント	役割	具体例
イベントバス	イベントの受け口（チャンネル）	デフォルトバス／カスタムバス／パートナーバス
イベント	「何かが起きた」を表すJSONデータ	EC2停止通知・注文確定・Salesforce更新
ルール	どのイベントをどこに送るかの条件と宛先	「source=ec2 かつ state=stopped → Lambda実行」
イベントパターン	ルールが適用されるイベントの条件式	`{"source": ["aws.ec2"]}`
ターゲット	イベントの送り先（最大5個まで）	Lambda・SQS・SNS・Step Functions・ECS など
スケジュール	時刻ベースでイベントを発生させる	毎日9時にバッチ処理を起動

3種類のイベントバス

┌───────────────────────────────────────────────────┐
│                 EventBridge                        │
│                                                   │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐ │
│  │ デフォルト    │  │ カスタム     │  │ パートナー   │ │
│  │ イベントバス  │  │ イベントバス │  │ イベントバス │ │
│  │              │  │              │  │              │ │
│  │ AWSサービス  │  │ 自社アプリ   │  │ Salesforce   │ │
│  │ からの通知   │  │ のイベント   │  │ Zendesk 等   │ │
│  └──────────────┘  └──────────────┘  └──────────────┘ │
└───────────────────────────────────────────────────┘

デフォルトバス：AWS自身のサービス（EC2・S3・RDSなど）が自動的にイベントを送るバス。追加設定不要で利用可能
カスタムバス：自社アプリケーションのイベントを流すために作成するバス。マイクロサービス間の連携に使う
パートナーバス：Salesforce・Zendesk・GitHub・Shopifyなど、SaaSサービスが直接イベントを送り込めるバス

イベントの流れとルーティング

EventBridgeを通るイベントの一生を追うと、こんな流れになります。

イベントパターンの書き方（例）

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["stopped", "terminated"]
  }
}

このパターンは「EC2インスタンスが停止または終了したとき」というルール。JSONの部分一致で条件を書けるため、プログラミング知識がなくても直感的に設定できます。

歴史と背景

2015年：前身となる「Amazon CloudWatch Events」がリリース。AWSサービスのイベントをLambdaやSNSに送る機能として登場
2019年11月：re:Invent 2019で「Amazon EventBridge」として独立・リブランド。SaaS統合（Zendesk・PagerDutyなど）、カスタムイベントバス、スキーマレジストリを追加
2021年：EventBridge Pipesのプレビュー開始。ポイントツーポイントの接続をよりシンプルに構築できる機能
2022年：EventBridge Pipesが正式リリース。フィルタリング・変換・エンリッチメントをノーコードで設定可能に
2023年：EventBridge Schedulerが強化。cron式・rate式でのスケジュール実行をより細かく制御できるように
現在：250以上のAWSサービスがデフォルトバスにイベントを送信。SaaSパートナーも30社以上に拡大

イベント駆動アーキテクチャの普及に伴い、マイクロサービス間の疎結合化・非同期処理化のニーズが高まり、EventBridgeはその中核を担うサービスとして定着しました。

類似サービスとの比較

EventBridgeと混同されやすいAWSの他のメッセージングサービスを整理します。

実務での使い分け目安：

こんなとき	使うサービス
「EC2が止まったらSlackに通知したい」	EventBridge → Lambda → Slack
「注文が来たら複数の処理を並行して走らせたい」	EventBridge or SNS
「処理が重いので順番にキューイングしたい」	SQS
「毎秒100万件のIoTデータを分析したい」	Kinesis

実務でのユースケース

1. インフラ監視の自動化

EC2やRDSが異常状態になったら自動でアラートを上げたり、復旧スクリプトを実行したりする。従来はCloudWatchアラームの設定が複雑でしたが、EventBridgeのルールで直感的に設定できます。

2. SaaS連携ワークフロー

Salesforceで商談ステータスが「成約」に変わったとき、自動的に社内の受注システムにデータを登録し、担当者にSlack通知を送るといった連携が、コード最小限で実現できます。

3. マイクロサービス間の非同期連携

注文サービス・在庫サービス・請求サービスが直接呼び合うと一つが止まったら全体が止まります。EventBridgeをハブにすることで、各サービスは「イベントを発行するだけ」で済み、障害時の影響を局所化できます。

4. 定期バッチ処理のスケジュール実行

「毎日深夜2時にデータ集計Lambdaを起動」のようなcron的な使い方もEventBridgeのSchedulerで対応できます。EC2を立てっぱなしにする必要がなくなり、コスト削減に直結します。