SQS vs SNS vs EventBridge — メッセージングサービスの選択基準
サービスを分割し始めると、すぐにぶつかる質問があります。「このメッセージは SQS、SNS、EventBridge のどれに送るべきか?」です。結論を先に書くと、1 つのコンシューマーが処理する作業を積んでおくバッファは SQS、同じメッセージを複数のサブスクライバーに即時プッシュするファンアウトは SNS、イベントの中身を見てルールでルーティングしたり SaaS 連携・スケジュールが必要なら EventBridge です。 そして実務での正解は、1 つを選ぶことではなく組み合わせであることが多いのです。料金は us-east-1 基準です。
ひと目でわかる比較 #
| 区分 | SQS | SNS | EventBridge |
|---|---|---|---|
| モデル | キュー (1:1) | pub/sub (1:N プッシュ) | イベントバス (ルールルーティング) |
| 配信方式 | コンシューマーがポーリング | サブスクライバーへプッシュ | ルール一致後にターゲット呼び出し |
| メッセージ保持 | デフォルト 4 日、最大 14 日 | なし (配信失敗時の再試行のみ) | なし (アーカイブは別機能) |
| 順序保証 | FIFO キューで可能 | FIFO トピックで可能 | なし |
| 料金 (100 万件あたり) | 約 $0.40 (FIFO $0.50) | 発行 約 $0.50 | カスタムイベント 約 $1.00 |
モデルの違い — 誰が受け取り、いつ消えるのか #
SQS はキューです。プロデューサーがメッセージを入れると、コンシューマーがポーリングで取り出して処理し、削除します。コンシューマーが落ちてもメッセージはキューに残り(デフォルト 4 日、最大 14 日)、処理中のメッセージは visibility timeout の間ほかのコンシューマーから見えなくなり、処理に失敗すれば再び現れます。指定回数失敗したメッセージを DLQ(デッドレターキュー)へ退避する再試行の仕組みまで含めて、「一度受け取った作業を失わないこと」に最適化されたサービスです。トラフィックスパイクをキューの長さで吸収するバッファ役が本業です。
SNS は pub/sub です。トピックに発行すると、サブスクライバー全員に即時プッシュされます。サブスクライバーは SQS キュー、Lambda、HTTP エンドポイント、メール、モバイルプッシュまで幅広く、フィルターポリシーでサブスクライバーごとに受け取るメッセージを絞れます。核心的な制約は保持がないことです。配信に失敗すると再試行ポリシーの分だけやり直して終わりで、後からサブスクリプションを追加しても過去のメッセージは受け取れません。
EventBridge はイベントバスです。発行側はバスにイベントを投げるだけで誰が受け取るかを知らず、受信側はイベント JSON の内容を条件にしたルールを作り、一致したイベントだけを受け取ります。差別化ポイントは 3 つです。S3、EC2 のような AWS サービスイベントがデフォルトバスに自動で流れ込み、Datadog、Stripe のような SaaS パートナーイベントを受け取れて、アーカイブ・リプレイとスケジューラー(cron の代替)が付いています。ターゲットも Lambda、SQS、Step Functions など 20 種類以上です。
料金 — 単価の差より課金単位を見ます #
- SQS: 100 万リクエストあたり約 $0.40(FIFO $0.50)、毎月 100 万リクエスト無料。リクエストは 64KB チャンク単位なので、256KB のメッセージ 1 件はリクエスト 4 件として計算されます。もう 1 つ、空のキューを短い間隔でポーリングするのも全部リクエスト数に入るため、ロングポーリング(WaitTimeSeconds 20 秒)がデフォルトであるべきです。
- SNS: 発行 100 万件あたり約 $0.50、毎月 100 万発行無料。SQS と Lambda への配信は無料で、HTTP 配信は 100 万件あたり約 $0.60 が追加されます。
- EventBridge: カスタムイベント 100 万件あたり約 $1.00 と 3 つの中で最も高く、無料枠もありません。代わりに、デフォルトバスに入ってくる AWS サービスイベントは課金されません。課金はやはり 64KB 単位です。
3 つとも 100 万件で $1 前後なので、普通の規模では料金は決定変数になりません。料金が問題になるのは億単位のイベントを扱う場合で、そのときは EventBridge と SQS の 2.5 倍の単価差が請求書にそのまま現れます。
組み合わせパターン — 選ぶのではなく、つなぐ #
- SNS → SQS ファンアウト: 注文イベントを SNS トピックに発行し、決済、配送、通知の各サービスが自分の SQS キューでサブスクライブします。ファンアウト(SNS)と欠落防止バッファ(SQS)を同時に得られる、最もよく使われる定石です。コンシューマーが落ちていても、メッセージはそれぞれのキューに積まれています。
- EventBridge → SQS: ルールルーティングで絞ったイベントをキューに積み、消費のペースをコンシューマー側が決められるようにします。S3 イベントを受けて処理するパイプラインの標準形です。
- トリガーとしての Lambda 連携: 3 つとも Lambda を直接呼び出せて、イベント駆動ワークロードならコンピューティング側の選択は Lambda vs Fargate で扱った基準をそのまま適用します。
避けるべき落とし穴 #
- EventBridge の遅延: イベントがルールを経てターゲットに届くまで平均 0.5 秒前後かかります。ユーザーリクエストの同期パスには入れません。
- 重要なメッセージを SNS 単独で使うこと: 保持がないため、サブスクライバーの障害時間の分だけメッセージが消えます。失ってはいけないメッセージは、必ず後ろに SQS を置きます。
- FIFO のスループット上限: FIFO キューは秒間 300 件(バッチで 3,000 件)が基本の上限です。高スループットモードで引き上げられますが、順序保証が本当に全メッセージに必要なのかをまず問い直すのが先です。ほとんどの場合、メッセージグループ単位の順序で十分です。
- 大きなペイロード: 3 つとも最大 256KB です。ファイルや大きな JSON は S3 に置いてメッセージにはキーだけを入れるポインター方式が標準で、64KB チャンク課金のため料金もこちらが安くなります。
選択の手順 #
- 受け手が 1 つかどうかを見ます: 作業を積んでコンシューマーが自分のペースで処理する構造なら、SQS で決まりです。バックグラウンドジョブ、バッチ投入、スパイク吸収がここです。
- 同じメッセージを複数が受け取るなら SNS を前に置きます: サブスクライバーごとに SQS キューを付けるファンアウトが基本形です。
- イベントの中身でルーティングするなら EventBridge です: フィールド値の条件、AWS サービスイベントの受信、SaaS 連携、スケジュール、アーカイブ・リプレイのどれかが必要ならここです。
- 遅延と順序の要件を検算します: 同期パスには 3 つとも入れないのが原則で、順序が必要なら FIFO のスループット上限も合わせて確認します。
- 料金は課金単位で見ます: 64KB チャンク、ポーリングのリクエスト数、HTTP 配信の追加分まで入れて初めて実際の請求書になります。使っていないサブスクリプションやルールが残っていないかは常時点検リストと合わせて見ます。
まとめ #
- 1 つのコンシューマーの作業バッファは SQS、複数サブスクライバーへのファンアウトは SNS、内容ベースのルーティングと SaaS 連携・スケジュールは EventBridge です。
- 保持、再試行、DLQ は SQS にしかありません。どんな構成でも、失ってはいけないメッセージは最後に SQS が受けるようにします。
- 料金は 100 万件あたり SQS $0.40、SNS $0.50、EventBridge $1.00 前後で、課金は 64KB チャンク単位です。単価差が意味を持つのは大量イベントのときだけです。
- EventBridge は平均 0.5 秒前後の遅延があるため、同期パスには入れません。FIFO は秒間 300 件(バッチ 3,000 件)が基本の上限です。
- 実務の正解は組み合わせです。SNS → SQS ファンアウトと EventBridge → SQS が、最もよく使われる 2 つの形です。