アプリケーション統合
SQS・SNS・EventBridge
SQSはポーリング型のキューで1対1配信、SNSはプッシュ型のPub/Subで1対多配信、EventBridgeはルールベースでイベントを複数ターゲットへ柔軟にルーティングするイベントバスです。
| 観点 | Amazon SQS | Amazon SNS | Amazon EventBridge |
|---|---|---|---|
| 通信モデル | ポーリング型キュー（1対1配信） | Pub/Sub型プッシュ通知（1対多配信） | イベントバス（ルールベースのルーティング） |
| メッセージ保持 | 最大14日間キューに保持 | Standardは組み込みリプレイなし、FIFOは最大365日のアーカイブ/リプレイに対応 | 保持されず即時ルーティング（アーカイブ/リプレイ機能あり） |
| 配信先 | ポーリングするコンシューマー（Standardはat-least-onceのため冪等処理が必要） | 複数のサブスクライバーへ同時配信 | 複数のターゲットへルールに基づき配信 |
| 順序保証 | 標準は保証なし、FIFOキューで保証可能 | 標準は保証なし、FIFOトピックで保証可能 | 保証なし |
| 典型用途 | 非同期処理のデカップリング、ワーカーキュー | ファンアウト配信、通知（Email/SMS/プッシュ） | SaaS連携、複数サービス間のイベント駆動連携、スケジュール実行 |
使い分けの判断基準
処理をキューイングしてコンシューマーに非同期処理させたいならSQS。Standardキューはat-least-once配信のため、重複を前提に冪等な処理を設計します。1つのイベントを複数の購読者に同時配信（ファンアウト）したいならSNS。SaaSパートナー連携や複雑なイベントパターンでのルーティング、スケジュール実行が必要ならEventBridge。多くの構成ではSNS→SQSのファンアウトパターン（各サブスクライバーにキューを持たせて再試行耐性を確保）を併用します。
試験で問われるポイント
- 「S3イベントを複数のLambdaで処理したい」→SNSファンアウト、「注文処理を非同期化してワーカーで順に処理」→SQSという判断がSAAで頻出
- SNS+SQSのファンアウトパターンによる疎結合設計は頻出アーキテクチャ
- EventBridgeのスケジューラ機能やSaaS連携（パートナーイベントソース）はDOP/SAPで問われやすい
関連するサービス解説
参照元
最終更新日: 2026-09-06
本ページの内容は、AWS公式ドキュメントを基に作成し、運営者が編集・監修しています。詳しくは編集・品質管理方針をご覧ください。