Amazon SNS による通知設計 - トピックとサブスクリプションのパターン
Standard と FIFO トピックの使い分け、SQS ファンアウトパターン、サブスクリプションフィルターによる条件付きルーティングを紹介します。
トピック設計とサブスクリプション
SNS トピックは Standard と FIFO の 2 種類があります。Standard トピックの毎秒のパブリッシュの数はリージョンごと / アカウントごとのクォータの範囲 (引き上げを申請できます) で、メッセージの順序はベストエフォートです。FIFO トピックはメッセージグループ ID ごとの厳密な順序保証と、メッセージ重複排除 ID による重複排除を提供します。FIFO トピックは SQS の標準キューと FIFO キューに配信でき、メールや SMS、HTTP/S などの顧客が管理するエンドポイントには配信できません。サブスクリプションプロトコルは SQS、Lambda、HTTP/HTTPS、メール、SMS、Amazon Data Firehose (旧 Kinesis Data Firehose) に対応しています。メッセージ属性を付与することで、サブスクリプションフィルターポリシーによる条件付きルーティングが可能になります。
ファンアウトパターンの設計
SNS + SQS ファンアウトパターンでは、SNS トピックに複数の SQS キューをサブスクライブし、1 つのパブリッシュで全キューにメッセージを配信します。各キューのコンシューマーは独立して処理を進められるため、1 つのコンシューマーが止まっても、他のキューの処理は続けられます。この構成の例は注文処理システムで、1 件の注文イベントが在庫更新キュー、メール通知キュー、分析記録キューに同時配信されます。Standard トピックのサブスクリプションのクォータは 1 トピックあたり 12,500,000 で、新しい処理はサブスクリプションを追加すればパブリッシャー側を変えずに足せます。クロスアカウントファンアウトではトピックポリシーで別アカウントの SQS キューからの Subscribe を許可し、マイクロサービス間を疎結合に保ちます。
サブスクリプションフィルターと配信保証
サブスクリプションフィルターポリシーは属性ベースとペイロードベースの 2 種類があります。属性ベースフィルターはメッセージ属性 (文字列の完全一致、前方一致、数値比較、exists 判定) で条件を定義します。ペイロードベースフィルターはメッセージ本文の JSON パスに対してフィルタリングを実行し、ネストされたフィールドにも対応します。フィルターは SNS 側で評価されるため、条件に合致しないメッセージはサブスクライバーに配信されず、ダウンストリームの処理コストとノイズを削減します。配信失敗時のリトライポリシーはエンドポイントの種類で異なり、SQS などの AWS が管理するエンドポイントでは 23 日間にわたって再試行され、HTTP/S は再試行の合計時間に上限があります。リトライ後も配信できないメッセージはデッドレターキュー (DLQ) に送信され、後から原因調査や再処理が可能です。DLQ のリドライブ機能で、問題解決後にメッセージを元のサブスクリプションに再配信できます。
FIFO トピックとメッセージ属性
FIFO トピックはメッセージの順序保証と重複排除を提供し、FIFO SQS キューとの組み合わせで厳密な順序処理を実現します。メッセージグループ ID でメッセージを論理的にグループ化し、グループ内の順序を保証します。メッセージ属性でメタデータ (イベントタイプ、優先度、送信元) を付与し、サブスクリプションフィルターポリシーで属性に基づくルーティングを実装します。メッセージデータ保護で PII (個人情報) を自動検出し、マスキングまたは拒否するポリシーを設定できますが、新規の顧客は 2026 年 4 月 30 日以降この機能を利用できません (既存の利用者は引き続き利用できます)。
設計の落とし穴と運用上の注意点
SNS の最大メッセージサイズは 256 KB で、これを超えるペイロードは S3 に格納しポインターのみを SNS で送信する Extended Client Library パターンを使います。FIFO トピックのスループット上限はメッセージグループあたり毎秒 300 メッセージであり、高スループットが必要な場合はメッセージグループ ID を分散させる設計にします。フィルターポリシーの複雑さが増すとデバッグが困難になるため、フィルター条件の属性は絞り、複雑なルーティングには EventBridge の利用を検討します。HTTP/HTTPS エンドポイントのサブスクリプション確認が完了しないとメッセージが配信されないため、確認トークンの処理をエンドポイントに実装します。メッセージの暗号化 (SSE) を有効にすると、サブスクライバー側の IAM ロールに KMS の復号権限が必要になる点も見落としがちです。
SNS と EventBridge の使い分け
SNS と EventBridge はどちらもイベント駆動アーキテクチャの中核ですが、特性が異なります。SNS はシンプルなファンアウトと多様なプロトコル (SQS、Lambda、HTTP、SMS、メール) への配信に向いています。EventBridge はイベントの構造に対するルールのパターンマッチ、スキーマレジストリ、SaaS との統合を備えます。実務的な使い分けとして、アプリケーション内部のファンアウト (注文 → 複数キュー) は SNS、サービス間のイベントルーティング (複雑な条件分岐、外部 SaaS イベント) は EventBridge が適しています。SNS の Standard トピックのサブスクリプションのクォータは 1 トピックあたり 12,500,000 で、EventBridge は 1 ルールあたりのターゲットの数に上限があり、ルールの数でスケールする設計です。
SNS の料金
SNS の料金はトピックの種類で決まり、Standard トピックはパブリッシュなどの API リクエストの数で課金されます。FIFO トピックは、パブリッシュとサブスクリプションのメッセージの数と、それぞれのペイロードのデータ量で課金されます。HTTP/S エンドポイントへの配信は通知の数で課金され、SQS への配信には料金がかかりません (SQS の料金は別)。SMS 配信は送信先の国に応じた従量課金です。属性ベースのメッセージフィルタリングは無料で、ペイロードベースはスキャンしたペイロードのデータ量で課金されます。
まとめ
SNS はトピックベースの Pub/Sub メッセージングで、ファンアウトパターンとサブスクリプションフィルターによる柔軟なメッセージルーティングを提供します。FIFO トピックで順序保証と重複排除を実現します。SQS との組み合わせで信頼性の高い非同期処理パイプラインを構築し、DLQ で配信に失敗したメッセージを捕捉します。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトと公式ドキュメントです。最新の仕様と料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。