EventBridge vs SNS vs SQS — イベント駆動アーキテクチャの使い分け

3サービスの基本的な役割

SQS（Simple Queue Service）:
  プロデューサーとコンシューマーをデカップリング
  コンシューマーがポーリングして処理（プッシュではなくプル）
  メッセージの永続化（最長14日間）
  1対1の処理（1メッセージは1コンシューマーが処理）

SNS（Simple Notification Service）:
  1対多のプッシュ通知（Pub/Sub）
  トピックに送ったメッセージを全サブスクライバーに配信
  プッシュ型（ポーリング不要）
  SQS, Lambda, HTTP, Email, SMS等に転送可能

EventBridge:
  AWSサービスイベントとカスタムイベントのルーティング
  複雑なフィルタリングルール
  スキーマレジストリ（イベント仕様の管理）
  クロスアカウント・クロスリージョンのイベント転送

ファンアウト（1→多）パターン

SNSファンアウト（シンプルな1→多）:
  OrderCreated SNSトピック
    ├── SQS: 在庫処理キュー
    ├── SQS: 通知処理キュー
    └── Lambda: 分析処理

EventBridgeファンアウト（条件付き1→多）:
  EventBus
    ├── ルール1: orderStatus=completed → Lambda（完了通知）
    ├── ルール2: orderValue>10000 → SNS（大口注文アラート）
    └── ルール3: orderRegion=JP → SQS（国内配送処理）

EventBridgeの高度なフィルタリング

EventBridgeはSNSより複雑な条件でルーティングできる。

// EventBridgeルール: 100万円以上の大口注文のみ処理
{
  "source": ["my-app.orders"],
  "detail-type": ["OrderCreated"],
  "detail": {
    "amount": [{"numeric": [">=", 1000000]}],
    "region": ["JP"],
    "status": [{"anything-but": "cancelled"}]
  }
}

SNSのフィルタリング（サブスクリプションフィルタポリシー）：

// SNS サブスクリプションフィルターポリシー
{
  "region": ["JP"],
  "status": [{"anything-but": "cancelled"}],
  "amount": [{"numeric": [">=", 1000000]}]
}

クロスアカウント・クロスリージョン

EventBridge:
  イベントバスポリシーでクロスアカウント送信可能
  クロスリージョンのイベントバスへのルーティング可能
  → 中央イベントバスパターン（セキュリティイベントの集約等）

SNS:
  クロスアカウントのSQS/Lambdaにサブスクライブ可能
  クロスリージョンは直接はできない（SNS→SQS→Lambda経由）

# EventBridgeのクロスアカウントポリシー
aws events put-permission \
  --event-bus-name central-security-bus \
  --action events:PutEvents \
  --principal arn:aws:iam::111111111111:root \
  --statement-id AllowAccount1 \
  --condition Type=StringEquals,Key=aws:PrincipalOrgID,Value=o-xxx

イベントアーカイブとリプレイ

EventBridgeにはイベントのアーカイブと再実行機能がある。

# イベントのアーカイブ設定
aws events create-archive \
  --archive-name order-events-archive \
  --event-source-arn arn:aws:events:ap-northeast-1:123456789012:event-bus/default \
  --retention-days 90 \
  --event-pattern '{"source": ["my-app.orders"]}'

# アーカイブからのリプレイ（障害復旧、デバッグ）
aws events start-replay \
  --replay-name debug-replay \
  --event-source-arn arn:aws:events:ap-northeast-1:123456789012:archive/order-events-archive \
  --event-start-time 2026-04-01T00:00:00Z \
  --event-end-time 2026-04-07T00:00:00Z \
  --destination '{
    "Arn": "arn:aws:events:ap-northeast-1:123456789012:event-bus/default"
  }'

選択基準の整理

SQSを使うべきケース:
  - 処理速度に差があるプロデューサー/コンシューマーのデカップリング
  - 処理失敗時の再試行とDLQ管理
  - ワーカーが複数いてジョブを分担する場合
  - メッセージを一定時間保持したい場合

SNSを使うべきケース:
  - シンプルな1→多のブロードキャスト
  - メール/SMS通知
  - 複数SQSへのファンアウト
  - モバイルプッシュ通知

EventBridgeを使うべきケース:
  - AWSサービスのイベント（EC2状態変化、S3イベント等）に反応したい
  - 複雑なフィルタリングが必要
  - クロスアカウント・クロスリージョンのイベントルーティング
  - サードパーティSaaSとのイベント統合
  - スキーマ管理が必要
  - イベントのアーカイブ・リプレイが必要

試験頻出ポイント

シナリオ	回答
処理速度差のあるシステムのデカップリング	SQS
1つのイベントを複数システムに配信	SNS（シンプル）またはEventBridge（複雑な条件）
AWSサービスのイベントをトリガーにしたい	EventBridge
大口注文だけ特定処理に流したい	EventBridge（数値条件フィルタ）
イベントをアーカイブして後でリプレイ	EventBridge

まとめ

SQS・SNS・EventBridgeはそれぞれ異なる目的で使う。複雑なイベントルーティングにはEventBridge、シンプルな1対多配信にはSNS、非同期キューイングにはSQSが適している。実際のアーキテクチャでは組み合わせて使うことが多い。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感