はじめに
この記事の目的
本記事は、AWSのイベント駆動アーキテクチャを実現する主要サービス「Amazon EventBridge」について、やさしく丁寧に解説することを目的としています。概要から仕組み、主要コンポーネント（イベントバス・ルール・ターゲット）、代表的なユースケース、利点や注意点まで幅広く扱います。
この記事で学べること
- EventBridgeが何をするサービスかを直感的に理解できます。
- イベントバス、ルール、ターゲットの役割が分かります。
- どんな場面で使うと効果的か、具体例を通して学べます。
対象読者
- クラウドアーキテクチャに興味があるエンジニアや運用担当者
- マイクロサービスやサーバレスを検討している方
- 既存のシステムにイベント駆動を導入したい企画担当者
前提知識
AWSの基本操作やサービスの概念に馴染みがあると読みやすいです。専門用語は最小限にし、具体例で補足しますので初心者にも配慮しています。
読み進め方のヒント
まず本章で目的と全体像をつかんでください。続く章で基礎→応用→実装の順に深めます。具体的なユースケースをイメージしながら読むと理解が早まります。
身近なイメージ例
ネットショップで「注文が入った」イベントが発生すると、在庫管理、請求処理、配送通知、分析ツールへ同時に情報を送る──EventBridgeはその“中継役”として働きます。
以降の章で、具体的な仕組みや設定、よくある導入パターンを丁寧に解説していきます。
Amazon EventBridgeとは？基本概要
概要
Amazon EventBridgeは、AWSが提供するサーバーレスのイベントバスです。アプリケーション、SaaS、AWSサービスで発生したイベントを受け取り、定義したルールに従ってさまざまなターゲットへ届けます。コンポーネント同士が直接呼び出し合うのではなく、イベントで連携することで疎結合な構成を簡単に作れます。
動きのイメージ
- あるサービスがJSON形式のイベントを発行します（例：EC2の状態変化、外部決済サービスの通知）。
- EventBridgeのイベントバスが受け取ります。
- ルールがイベントを判定し、該当するターゲット（Lambda、SQS、Step Functionsなど）へ送ります。
主な特長
- サーバーレスで運用負荷が少ない。
- コンポーネントを疎結合にでき、変更の影響範囲を小さくできます。
- 自動でスケールし、多数のイベントを安定して処理できます。
使いどころのイメージ
- ファイルアップロード後に自動処理を走らせる。
- SaaSの外部通知を自社処理に取り込む。
- システム間の非同期連携を簡単に作る。
注意点として、イベント形式やサイズ制限を確認して設計してください。
EventBridgeで解決できる課題・ユースケース像
従来のシステム連携は、ポーリングやバッチ、直接API呼び出しが中心でした。たとえば定期的に外部APIへ問合せして処理結果を確認したり、夜間のバッチでデータをまとめて処理したりします。この方式は不要なAPI呼び出しやリソース消費、システム間の結合度の高さ、サーバーやキューのスケーリング・運用負担といった課題を生みます。
EventBridgeはイベントが発生した瞬間に配信します。これによりポーリングが不要になり、処理の応答性とリソース効率が向上します。送信元と送信先はEventBridgeを介するため互いの実装に依存せず、疎結合な連携を実現します。マイクロサービスやサーバーレス構成に特に向きます。
代表的なユースケースと具体例：
-
AWSサービスのイベントでワークフローを起動
例: S3にファイルがアップロードされたらLambdaでサムネイル生成、CodePipelineの状態変化でStep Functionsを起動。 -
SaaSと社内システムの連携
例: StripeやSalesforceのイベントをEventBridgeに受け、Lambdaで社内データベースを更新。 -
マイクロサービス間の非同期連携
例: 注文サービスが”OrderPlaced”イベントを出し、在庫・請求・発送サービスが独立して処理。 -
EventBridge Schedulerによる定期ジョブ
例: 毎朝のレポート生成やバッチ起動をスケジュールで自動化。 -
EventBridge Pipesでの統合パイプライン
例: イベントをフィルタ・変換してKinesisやLambdaへ渡す一連の処理を簡潔に構築。
このようにEventBridgeは、不要な負荷を減らし運用負担を軽くしつつ、拡張しやすいイベント駆動の連携を可能にします。
EventBridgeのアーキテクチャの中核：イベントバス
EventBridgeの中心は「イベントバス」です。イベントバスはイベントを受け取り、ルールで振り分けてターゲットへ送る中継点の役割を果たします。イメージとしては、情報を受け取る郵便局で、届いた手紙（イベント）を宛先（ルール）に応じて配達します。
イベントバスの種類
- デフォルトイベントバス: AWSのサービスから自動で来る通知を受け取ります。例: EC2やCodeBuildの状態変化を受け取る場です。
- カスタムイベントバス: 自分のアプリや社内システムが送る独自イベント用です。例: 注文が入ったときにアプリからイベントを投げる用途。
- パートナーイベントバス: ZendeskやShopifyなど外部SaaSと連携するための専用バスです。SaaS側から直接イベントが届きます。
クロスリージョン配信と集約
異なるリージョンのイベントを一つに集めたり、別リージョンへ転送できます。たとえば各リージョンの監視イベントを中央リージョンで集約して一括処理すると運用が楽になります。
運用で注意する点
イベントバスは受け取りと転送が中心なので、アクセス権（イベントバスポリシー）やスキーマ管理、モニタリング（配信失敗や遅延の監視）を整えると安定します。
ルール（Rules）：どのイベントをどこに飛ばすかを定義
概要
ルールはイベントバスに対して「どのようなイベントが発生したら、どのターゲットへ送るか」を決める設定です。たとえば「EC2インスタンスが stopped になったらSNSへ通知する」といった動作を実現します。ルールは複数作成でき、同じイベントに対して複数のルールが動作します。
イベントパターンの仕組み
ルールはイベントパターンというJSONで条件を記述します。ソース名、イベントタイプ、特定フィールドの値などでマッチングできます。簡単な例：
{"source":["aws.ec2"], "detail-type":["EC2 Instance State-change Notification"], "detail":{"state":["stopped"]}}
この例はEC2の停止イベントだけを拾います。
ルールの作り方（具体例）
- 条件を考える（例：EC2の停止、S3へのファイル作成など）
- マッチするフィールドをイベントパターンで指定
- ターゲットを設定（SNS、Lambda、SQSなど）
ファンアウトと注意点
同一イベントに複数ルールを設定すると、イベントを複数のターゲットへ配信できます（ファンアウト）。配信遅延や料金、重複処理に注意してください。
コンソールでの支援
AWSコンソールはビジュアルなルールビルダーを提供します。直感的に条件を組めるので、初心者でも試しやすいです。
ターゲット（Targets）：イベントの送り先となるAWSサービス
概要
EventBridgeは受け取ったイベントをさまざまなAWSサービスに送れます。代表的なターゲットにはAWS Lambda（サーバーレス関数実行）、AWS Step Functions（ワークフロー実行）、Amazon SNS/SQS（通知・キュー）、Amazon Kinesis Data Streams/Firehose（ストリーム処理）、Amazon ECS/Fargate（コンテナ実行）、Amazon S3（保存）などがあります。2025年にはSQSのフェアキュー（公平キュー）もターゲットに追加され、より公平なメッセージ処理が可能になりました。
主なターゲットと具体例
- Lambda：短い処理やリアルタイム変換に最適。例：画像サムネイル生成。
- Step Functions：複雑な順序や分岐のある処理に適する。例：注文処理のステップ化。
- SNS/SQS：通知や耐久性のあるキューイング。例：ユーザー通知や遅延処理。フェアキューは処理の偏りを減らします。
- Kinesis/Firehose：大量データのストリーム処理やS3への取り込み。
- ECS/Fargate：コンテナで重めのバッチ処理を実行。
- S3：イベント内容をそのまま保存する一部シナリオ。
配信制御（再試行・最大イベント年齢・DLQ）
各ターゲットで再試行回数や間隔、イベントの最大存続時間（年齢）、失敗時に送るデッドレターキュー（DLQ）を設定できます。例えばLambdaが繰り返し失敗する場合、一定回数後にDLQへ回して原因分析に使えます。
イベント変換と選び方のポイント
EventBridgeは送信時に入力の一部を抜き出す「入力変換（Input Transformer）」や固定値の付与ができます。低遅延ならLambdaやECS、高耐久ならSQS/Kinesis、ワークフロー管理が必要ならStep Functionsを選ぶと良いです。
