旅行会社の新規事業開発部。
ケンイチはクラウドの設計図を見つめながらつぶやいた。
「予約が入ったらメールを送り、
決済が完了したらチケットを発行して、
キャンセルがあったら在庫を戻す…
これ、どうやって全部つなぐんですか？」
課長はホワイトボードに丸をいくつか描いた。
「今までは“直接つなぐ”設計をしていたよな？」
ケンイチはうなずく。
「はい。AからB、BからCへと、
コードでつなぎました。」
課長は首を振った。
「それだと、システムが増えるほど複雑になる。
そこで使うのがAmazon EventBridgeだ。」
「まず“Event（イベント）”とは何か。」
課長は書いた。
「EventBridgeは“出来事の交通整理役”だ。」
ケンイチは首をかしげる。
「交通整理？」
「例えば、予約完了というイベントが発生したら――」
「EventBridgeは
“誰に知らせるか”をルールで決めてくれる。」
つまり、
システム同士を直接つながなくていい
ルールで自動分岐できる
のがポイントだ。
ケンイチはAWSの用語集を開いた。
「SNSやSQSも通知じゃないですか？」
課長は整理した。
| サービス | 役割 | ざっくり言うと |
|---|---|---|
| SNS | 同時通知 | 一斉連絡メール |
| SQS | キュー保存 | 順番待ち箱 |
| EventBridge | 条件分岐通知 | 交通整理センター |
「EventBridgeは
“条件に応じて処理を振り分ける”のが強みだ。」
課長は旅行会社の実例を出した。
「例えば、
“売上が1日100万円を超えたらSlack通知”
“キャンセル率が5％を超えたら分析処理起動”」
「これ、全部EventBridgeでできる。」
ケンイチの目が輝いた。
「つまり…
システムをゆるくつなぐ仕組みなんですね。」
「その通り。
クラウド設計では“疎結合”が重要だ。」
EventBridgeは多くの企業で“イベント駆動設計”の中核として使われています。
例えばAWS公式事例では、
ShopifyなどのSaaSとAWSを連携し、注文発生をきっかけに分析基盤を起動する仕組みが紹介されています。
また金融・EC企業では、
決済完了 → 不正検知処理起動
ログイン失敗多発 → セキュリティ通知
といった自動処理をEventBridgeで制御しています。
マイクロサービス化が進む企業ほど、
EventBridgeのようなイベント連携基盤は重要になります。
参考：
AWS公式ドキュメント
https://aws.amazon.com/jp/eventbridge/
A. データを保存する
B. 出来事を条件で振り分ける
C. 仮想サーバーを起動する
A. 一斉通知のみ
B. 条件付きの自動連携
C. 大容量ファイル保存
A. システムをゆるく連携できる
B. システムを直接つなぐ
C. サーバー性能を上げる
クイズ1：B → ルールでイベントを振り分ける
クイズ2：B → 条件分岐型の連携が強み
クイズ3：A → 疎結合で拡張しやすい設計