疎結合アーキテクチャの土台となるのが、メッセージング3兄弟とも言える SQS・SNS・EventBridgeです。それぞれ思想が異なるため、正確な使い分けが重要です。

SAA レベル：基礎概念

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

サービス	通信モデル	特徴
SQS	キューイング（1対1）	メッセージは1つのコンシューマーが処理し、処理後に削除
SNS	パブリッシュ/サブスクライブ（1対多）	発行したメッセージを複数のサブスクライバーに配信
EventBridge	イベントバス（ルールベースの1対多）	イベントの内容に基づいた柔軟なルーティングが可能

SAA 試験のポイント

SQSは「キューに入れて、誰か1人が処理する」、SNSは「イベントを発行して、登録された全員に届く」という違いが基本です。同じメッセージを複数の異なるシステムに同時配信したい場合はSNS、1つのタスクを確実に1回処理させたい場合はSQSという判断軸がSAAで問われます。

SNS + SQSによるファンアウトパターン

SAA 頻出

SNSから直接複数のLambdaを呼び出すことも可能ですが、SNS+SQSの組み合わせにすることで、各コンシューマー側の処理速度に差があっても、SQSがバッファとして機能し、メッセージ消失を防げます。この耐久性の違いがSAAで問われます。

SAP レベル：高度な設計シナリオ

EventBridgeのルールベースルーティング

SAP 試験のポイント

EventBridgeは、イベントの中身（JSON構造）に基づいたきめ細かいルールマッチングでルーティング先を決定できる点がSNSと決定的に異なります。「注文金額が1万円以上のイベントだけを特定のLambdaに転送する」といった、コンテンツベースのルーティングが可能です。さらに、EventBridgeは多数のSaaS（サードパーティ）パートナーからのイベントを直接受信できるという統合の広さも特徴です。

観点	SNS	EventBridge
ルーティング基準	トピック単位（サブスクリプションフィルタは可能）	イベント内容に基づく詳細なルールマッチング
サードパーティ統合	限定的	多数のSaaSパートナーとネイティブ統合
スキーマ管理	なし	スキーマレジストリによる構造管理

スキーマレジストリとイベント駆動設計のガバナンス

EventBridgeのスキーマレジストリは、流通するイベントの構造（JSON Schema）を自動検出・登録し、コード生成（バインディング）にも活用できる
マイクロサービスが増えるほどイベント構造の非互換な変更がシステム全体に波及するリスクが高まるため、スキーマのバージョン管理と後方互換性の担保がSAPレベルの設計論点になる

設計上の落とし穴

「EventBridgeがあれば何でも解決する」という判断は誤りです。**確実に1回だけ処理させたい（重複実行を避けたい）順序性の厳密なタスク処理にはSQS（FIFOキュー含む）**が適しており、EventBridgeは主に疎結合なイベント通知・ルーティングに向いています。要件（配信保証、順序性、フィルタリングの複雑さ）に応じた使い分けが問われます。

FIFOキューによる順序保証

標準SQSキューはベストエフォート型の順序保証（順序が入れ替わる可能性がある）
FIFOキューを使うと、メッセージグループID単位での厳密な順序保証と、重複排除（Deduplication）が可能になる。ただしスループットは標準キューより制限される

まとめ

SAA: SQS（1対1キューイング）、SNS（1対多パブサブ）、SNS+SQSファンアウトパターンの基本を理解する。
SAP: EventBridgeのコンテンツベースルーティングとスキーマレジストリ、FIFOキューによる順序保証、要件に応じた3サービスの使い分けができる。

次は **Kinesis（Data Streams、Firehose、Data Analytics）**を見ていきましょう。