AWS EventBridgeでイベント駆動設計｜SES案件対応

⚡ 3秒でわかる！この記事のポイント

EventBridgeはAWSのイベントバスサービスで、マイクロサービス間連携の核
SNS/SQSとの使い分けを理解することがSES面談突破の鍵
EC・金融業界のSES案件でEventBridge経験者の需要が急増中

「イベント駆動アーキテクチャ（EDA）って聞いたことあるけど、実際にどう使うの？」——AWSを使うSESエンジニアなら、一度は疑問に思ったことがあるはずです。

AWS EventBridgeは、2026年のサーバーレスアーキテクチャにおいて最も重要なサービスの一つです。マイクロサービス間の連携、外部SaaSとの統合、スケジュール実行——これらをEventBridge一つで実現できます。

この記事では、EventBridgeの基本概念からSES案件での活用ポイントまで、実践的に解説します。

AWS EventBridgeとは？基本概念と位置づけ

イベント駆動アーキテクチャ（EDA）の考え方

イベント駆動アーキテクチャとは、**「何かが起きたら（イベント）、それに反応して処理を実行する」**という設計パターンです。

従来の同期通信型（REST API直接呼び出し）との違いを比較しましょう。

特性	同期通信（REST）	イベント駆動（EDA）
結合度	密結合（呼び出し元と先が直結）	疎結合（イベントバスを介する）
障害の影響	連鎖的（1つ落ちると全停止）	局所的（他のサービスに影響しない）
スケーラビリティ	全体のボトルネックに依存	サービスごとに独立してスケール
リアルタイム性	高い（即時レスポンス）	やや遅延（非同期処理）

EventBridgeは、このEDAをAWSネイティブで実現するサービスです。

SNS/SQSとの使い分け

AWSにはメッセージング系サービスが複数あり、混同しがちです。

サービス	主な用途	使い分けの判断基準
EventBridge	イベントのルーティング・フィルタリング	複数のターゲットにルールベースで配信したい
SNS	Pub/Subメッセージング	シンプルなファンアウト（1対多）配信
SQS	メッセージキューイング	処理の順序保証やバッファリングが必要

判断のポイント：イベントの内容に基づいてルーティングしたい場合はEventBridge、単純に複数の宛先に同じメッセージを送る場合はSNS、処理の順序保証やリトライが必要な場合はSQSを選びます。

実際の案件では、EventBridge → SNS → SQS と組み合わせて使うケースが最も多いです。

EventBridgeの主要コンポーネント

イベントバス・ルール・ターゲット

EventBridgeは3つの主要コンポーネントで構成されています。

イベントバス（Event Bus） イベントが流れる「パイプ」です。デフォルトバスの他に、カスタムバスを作成できます。

ルール（Rule） イベントをフィルタリングする条件です。JSONベースのイベントパターンで定義します。

ターゲット（Target） ルールにマッチしたイベントを受け取る宛先です。Lambda, SQS, SNS, Step Functionsなど、20以上のAWSサービスをターゲットに設定できます。

// イベントパターンの例
{
  "source": ["com.myapp.orders"],
  "detail-type": ["OrderCreated"],
  "detail": {
    "amount": [{ "numeric": [">", 10000] }]
  }
}

この例では、「注文が作成され（OrderCreated）、金額が10,000円を超える」イベントだけをフィルタリングしています。

スキーマレジストリとスキーマ検出

EventBridgeのスキーマレジストリは、イベントの構造（スキーマ）を自動的に検出・管理する機能です。

# スキーマの自動検出を有効化
aws schemas create-discoverer \
  --source-arn arn:aws:events:ap-northeast-1:123456789:event-bus/my-bus

# 検出されたスキーマの一覧表示
aws schemas list-schemas --registry-name discovered-schemas

スキーマレジストリを活用することで、以下のメリットがあります。

イベントの構造がドキュメント化される（手動で仕様書を書く必要がない）
スキーマから型定義を自動生成できる（TypeScript, Python, Java対応）
イベントの破壊的変更を検知できる

実践：EventBridgeでマイクロサービス連携を構築

注文→決済→在庫→通知のイベントフロー

EC系の典型的なマイクロサービス連携をEventBridgeで実装してみましょう。

注文サービス → [OrderCreated] → EventBridge
                                    ├→ 決済サービス（Lambda）
                                    ├→ 在庫サービス（Lambda）
                                    └→ 通知サービス（SNS → メール）

各サービスは独立して動作し、EventBridgeを介してイベントを受け取ります。決済サービスが落ちても、在庫サービスと通知サービスは正常に動作し続けます。

カスタムイベントバスの作成手順

# 1. カスタムイベントバスの作成
aws events create-event-bus --name my-ecommerce-bus

# 2. ルールの作成（注文作成イベントをフィルタ）
aws events put-rule \
  --name OrderCreatedRule \
  --event-bus-name my-ecommerce-bus \
  --event-pattern '{
    "source": ["com.myapp.orders"],
    "detail-type": ["OrderCreated"]
  }'

# 3. ターゲットの設定（Lambda関数）
aws events put-targets \
  --rule OrderCreatedRule \
  --event-bus-name my-ecommerce-bus \
  --targets "Id"="payment-target","Arn"="arn:aws:lambda:ap-northeast-1:123456789:function:ProcessPayment"

# 4. テストイベントの送信
aws events put-events --entries '[
  {
    "Source": "com.myapp.orders",
    "DetailType": "OrderCreated",
    "Detail": "{\"orderId\": \"ORD-001\", \"amount\": 15000, \"userId\": \"USR-123\"}",
    "EventBusName": "my-ecommerce-bus"
  }
]'

EventBridge × Lambda × Step Functionsの統合パターン

EventBridgeは単体でも強力ですが、LambdaやStep Functionsと組み合わせることで、より複雑なワークフローを構築できます。

EventBridge → Step Functions → [並列処理]
                                ├→ Lambda: バリデーション
                                ├→ Lambda: データ変換
                                └→ Lambda: 外部API連携
                              → [成功] → SQS → 後続処理
                              → [失敗] → SNS → エラー通知

Step Functionsとの組み合わせが効果的なケース

複数のステップを順序立てて実行する必要がある
条件分岐（if/else）が複雑
リトライ・エラーハンドリングをきめ細かく制御したい
処理の可視化（実行履歴のグラフ表示）が必要

AWS公式ドキュメントにも、Step Functionsとの統合パターンが詳細に記載されています。

EventBridgeイベント駆動アーキテクチャ構成図

運用・監視のベストプラクティス

DLQ（デッドレターキュー）の設定

イベントの配信に失敗した場合に備えて、**DLQ（Dead Letter Queue）**を必ず設定しましょう。

# DLQ用のSQSキューを作成
aws sqs create-queue --queue-name eventbridge-dlq

# ルールにDLQを設定
aws events put-targets \
  --rule OrderCreatedRule \
  --event-bus-name my-ecommerce-bus \
  --targets "Id"="payment-target","Arn"="arn:aws:lambda:...","DeadLetterConfig"={"Arn":"arn:aws:sqs:..."}

DLQがないと、配信失敗したイベントが消失します。本番環境では必ず設定してください。

CloudWatchでのイベント監視

EventBridgeはCloudWatchメトリクスと自動連携しています。

監視すべき主要メトリクス

Invocations：ルールがマッチした回数
FailedInvocations：ターゲットへの配信失敗回数
ThrottledRules：スロットリングされたルール数
MatchedEvents：イベントパターンにマッチした回数

# CloudWatchアラームの設定例
aws cloudwatch put-metric-alarm \
  --alarm-name "EventBridge-FailedInvocations" \
  --metric-name "FailedInvocations" \
  --namespace "AWS/Events" \
  --statistic Sum \
  --period 300 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions "arn:aws:sns:..."

SES案件でEventBridgeが求められる場面

需要のある業界と案件例

EventBridge経験者が求められるSES案件の傾向です。

業界	案件例	月額単価目安
EC	注文処理基盤のマイクロサービス化	70〜90万円
金融	リアルタイム不正検知システム	80〜100万円
SaaS	マルチテナント通知基盤	75〜95万円
物流	配送ステータス連携基盤	65〜85万円