Amazon SNSとは｜Pub/Sub通知の仕組み・配信先・FIFO/フィルタリングと採用判断を実装者目線で解説

Amazon SNS（Simple Notification Service／シンプル ノーティフィケーション サービス）は、AWSが提供するPub/Sub（出版・購読）型のフルマネージドなメッセージング配信サービスです。送り手は「トピック」というチャネルへメッセージを発行するだけで、そのトピックを購読するSQSキューやLambda関数、HTTPエンドポイント、メールや携帯のSMSまで、登録済みの宛先すべてへ一斉に配られます。この記事で扱うのは、トピックとサブスクリプションの仕組み、アプリ間連携（A2A）とアプリから人への通知（A2P）という2つの用途、1つの発行を複数キューへ同報するファンアウト、標準トピックとFIFOトピックの違い、宛先ごとに配信を絞るフィルターポリシー、64KB単位・月100万件無料の従量課金、そしてSQSやEventBridgeといつ使い分けるかの判断です。SQS・SESとの三者比較は別記事に譲り、SNSで何ができ、どう組み、いつ選ぶかに絞ります。

まとめ：SNSは1つの発行を多数の宛先へ同報するPub/Subのハブ

先に結論を示します。Amazon SNSは、1回発行したメッセージを、登録済みの複数の宛先へ押し出し型（プッシュ）で同時配信する、サーバー管理の要らないメッセージング基盤です。中核はトピックとサブスクリプションで、送り手はトピックへ発行するだけ、受け手はそのトピックを購読するだけで疎結合につながります。宛先はSQS・Lambda・HTTP/HTTPSといったシステム同士の連携先から、メール・SMS・モバイルプッシュといった人への通知先まで幅広く選べます。

向くのは、あるイベントを起点に複数の処理を並行で走らせたい、通知の送り手と受け手を互いのURLや実装から切り離したい、というケースです。逆に、1件のメッセージを1つのワーカーが順番に取り出して処理したいだけなら、プッシュのSNSより取り出し型（プル）のSQS単体が素直に収まります。まず「1対多の同報が要るか」を起点に考え、要るならSNS、単なるキューイングならSQS、という順序で選ぶと外しません。

SNSの基本｜トピックとサブスクリプションで成り立つPub/Sub

SNSを理解する近道は、「トピックという掲示板に貼れば、購読者全員に配られる」という一点をつかむことです。ここでは全体像から入ります。

Amazon SNSとは何か｜トピックへ発行し購読者へ届く仕組み

Amazon SNSは、メッセージの発行（publish）と配信（deliver）を代行するマネージドサービスです。送り手（パブリッシャー）はトピックを1つ作り、そこへメッセージを発行します。受け手（サブスクライバー）は、そのトピックへ自分の宛先（エンドポイント）を登録してサブスクリプションを作る形です。以後、トピックへ発行されたメッセージは、購読しているすべての宛先へSNS側から押し出されます。送り手は誰が受け取るかを知る必要がなく、受け手も送り手のURLを知る必要がありません。この疎結合が、システムを部品ごとに独立して改修できるようにする土台になります。SNSはSQSやSESと名前が似ていますが役割が異なり、三者の違いと使い分けはAWS SQS・SNS・SESの違いと使い分けの解説で整理しています。

配信できる宛先の種類｜SQS・Lambda・HTTP・メール・SMS・プッシュ

SNSが配信できる宛先は幅広く、大きく2系統に分かれます。システム同士をつなぐ宛先が、Amazon SQSキュー、AWS Lambda関数、HTTP/HTTPSエンドポイント、そしてログや分析基盤へ流すAmazon Data Firehose。人へ届ける宛先が、Eメール（プレーンとEmail-JSON）、携帯電話のSMSテキスト、スマートフォンアプリへのモバイルプッシュ通知です。加えてDatadogやSplunkといった外部サービスプロバイダーへの配信も選べます。宛先はプロトコルごとにサブスクリプションとして登録し、1つのトピックへ異なる種類の宛先を混在させられる仕組みです。1回の発行で、SQSキューへ処理を投げつつ運用チームへメール通知する、といった構成も組めます。

SNSの2つの使い道｜アプリ間連携（A2A）と人への通知（A2P）

SNSは用途で大きく2つに分かれます。混同すると設計を誤るため、A2AとA2Pを分けて押さえます。

A2A｜SQS・Lambdaと組むアプリケーション間メッセージング

A2A（Application to Application）は、システムの部品同士をSNSでつなぐ使い方です。宛先はSQS・Lambda・HTTP/HTTPS・Firehoseで、あるサービスが発行したイベントを、別のサービスが購読して処理します。決済が完了したというイベントを1度発行すれば、在庫更新のキュー、メール通知のLambda、分析基盤のFirehoseが同時に動く、といった構成が典型です。SNSはHTTPやLambda宛の配信に失敗すると自動で再試行し、それでも届かないメッセージはデッドレターキュー（DLQ）としてSQSへ退避できます。購読側の処理をサーバーレスで組むなら、実行基盤の考え方はAWS Lambdaとはの解説が参考になります。

A2P｜メール・SMS・モバイルプッシュでシステムから人へ届ける通知

A2P（Application to Person）は、システムから人へ直接通知する使い方です。宛先はEメール、SMS、モバイルプッシュで、監視アラートを担当者のメールへ、ワンタイムパスワードを利用者のSMSへ、といった通知に向きます。ただしA2Pには用途の線引きがあります。SNSのメールは購読者向けの簡易なテキスト通知が中心で、差出人やドメインを整えて顧客へHTMLメールを大量配信する用途には向きません。顧客向けのメール配信は、送信に特化したAmazon SESとはの解説で扱う領域です。運用アラートやシステム通知はSNSのA2P、マーケティングやトランザクションのメールはSES、と役割で分けるのが実務の定石になります。

標準トピックとFIFOトピック｜順序保証・重複排除とフィルタリング

トピックには2種類あり、選び方で配信の性質が変わります。順序と重複の扱い、そして宛先を絞るフィルタを押さえます。

標準トピックとFIFOトピックの違い｜順序保証と重複排除の有無

標準トピック（Standard）は、高いスループットと最善努力の順序で、多様な宛先へ配信できる汎用型です。まれにメッセージの順序が入れ替わったり、同一メッセージが2回配信されたりする可能性を許容する代わりに、事実上無制限のスループットを得られます。FIFOトピック（First-In-First-Out）は、発行した順序を厳密に守り、重複を排除して1回だけ配信する型で、Amazon SQS FIFOキューと組み合わせて使う点が特徴です。順序と一意性が壊れると業務が破綻する、金融取引や在庫の増減のような処理に向きます。FIFOは順序保証と引き換えにスループットや購読できる宛先の種類に制約があるため、順序が問われない大半の通知・連携は標準トピックで足ります。両者の性質を対比すると次のとおりです。

迷ったら、順序と重複排除が業務要件に含まれるかで判断します。含まれないなら標準トピックが素直です。

サブスクリプションフィルターポリシー｜宛先ごとに配信を絞る仕組み

1つのトピックに複数の宛先を束ねると、宛先ごとに「欲しいメッセージだけ受け取りたい」場面が出てきます。この振り分けを担うのが、サブスクリプションフィルターポリシーです。発行時に付けたメッセージ属性（またはメッセージ本文）に対して、購読側ごとにJSONで条件を設定すると、条件に合うメッセージだけがその宛先へ配信される仕組みです。地域が「東京」のイベントだけを東京担当のキューへ、重大度が「高」のアラートだけを緊急通知のLambdaへ。こうした振り分けを、送り手側にif文を書かずに実現できます。フィルタで弾かれたメッセージは配信されないため、購読側で不要なメッセージを受け取って捨てる処理も要らず、配信コストの無駄を抑えられます。

ファンアウトと配信の信頼性｜複数キューへの同報とリトライ・DLQ

SNSがよく採用される理由の中心が、ファンアウトと配信の粘り強さです。設計の要になる2点を掘り下げます。

ファンアウト｜1回の発行を複数のSQSキューへ同報する並列構成

ファンアウト（fan-out）は、SNSトピックに複数のSQSキューを購読させ、1回の発行で全キューへ同じメッセージを複製して配る構成です。各キューの先には別々のワーカーが並び、注文イベント1件から、決済処理・在庫引当・配送手配を並行で走らせる、といった並列処理を組めます。SNS直結のLambdaと違い、間にSQSを挟むことで、購読側が一時的に落ちていてもメッセージがキューに滞留し、復旧後にまとめて処理できます。ピーク時の負荷をキューで吸収する緩衝材にもなる点が実務での利点です。この「SNSで配る・SQSで受け止める」の組み合わせが、AWS上の疎結合な非同期アーキテクチャの定番パターンです。取り出し型のキューイングの詳細は、三者比較の記事でSQSの節を参照してください。

配信リトライとデッドレターキュー｜届かないメッセージの退避と再処理

配信は必ず成功するとは限りません。SNSは宛先の種類ごとに再試行のポリシーを持ち、HTTP/HTTPSやLambda宛の一時的な失敗には自動でリトライをかけます。それでも規定回数内に届かなかったメッセージは、サブスクリプションにデッドレターキュー（SQSキュー）を設定しておくと、そこへ退避され、失われずに残る仕組みです。退避したメッセージは後から原因を調べて再処理でき、通知の取りこぼしを防げます。リトライやDLQ行きといった配信結果のイベントを起点に別の処理へつなぎたい場合は、イベントの振り分けにAmazon EventBridgeとはの解説が組み合わせの参考になります。なお、トピックへ発行できる相手やアクセスの範囲は、トピックポリシーとIAMで制御する設計です。どのアカウントやサービスに発行・購読を許すかの権限設計は、AWS IAMとはの解説の考え方が土台になります。

料金と制限｜64KB課金・月100万件無料の従量課金とメッセージサイズ

SNSは発行と配信の量で課金される従量制です。何が課金対象かの骨格と、押さえておく制限を整理します。

標準トピックの従量課金｜月100万件無料と配信プロトコル別の単価

課金の中心は、トピックへの発行リクエスト数と、宛先への配信数です。標準トピックのAPIリクエストは月100万件までが無料枠で、超過分は100万件あたり0.50ドルが基本です（2026年7月時点）。課金は64KB単位で、1回の発行でも256KBのペイロードなら4リクエストとして数えられます。配信は宛先の種類で単価が分かれ、HTTP/HTTPSは100万件あたり0.60ドル（月10万件無料）、Eメール・Email-JSONは10万件あたり2.00ドル（月1,000件無料）、モバイルプッシュは100万件あたり0.50ドル（月1,000件無料）が目安です。SMSは宛先の国ごとに別建ての料金がかかり、他プロトコルより単価が高くなります。SQSやLambdaといったAWS内部への配信は追加料金がかからない一方、SQS側やLambda側の利用料は別途発生する点には注意が必要です。単価は小さく見えても、発行と配信の両方に課金される点、SMSが高めな点を見落とすと見積もりがずれます。

メッセージサイズとFIFOの課金｜256KB上限と1KB単位の丸め

1メッセージの最大サイズは256KBです（2026年7月時点）。これを超える大きなデータを配りたい場合は、本体をS3に置き、SNSにはその参照（キー）だけを載せる設計にします。FIFOトピックの課金は標準トピックと数え方が異なり、1KBから256KBまでを1メッセージとして課金し、1KB未満のメッセージは1KBに切り上げて計算されます。順序保証と重複排除の価値と引き換えに、FIFOは標準トピックより割高になりがちなため、順序が要件でないのに一律FIFOを選ぶのは過剰投資です。まず標準トピックで組み、順序や重複排除が業務上どうしても必要な経路だけをFIFOに切り替える、という進め方がコストを抑えます。

Amazon SNSを採用すべき条件と見送って別方式に寄せる場面

ここは言い切ります。SNSはすべての連携で正解になるわけではありません。向く条件と、あえて選ばない場面を分けて示します。

SNSの採用が向く条件｜1対多の同報とプッシュ型のリアルタイム通知

効果が出るのは、1つのイベントを複数の宛先へ同時に配りたいケースです。マイクロサービス間でイベントを配って複数の処理を並行させたい、SNS＋SQSのファンアウトで疎結合な非同期パイプラインを組みたい、監視アラートを担当者のメールやSMSへ即時にプッシュしたい、といった用途にはまります。宛先を後から足しても送り手のコードは変わらず、フィルターポリシーで宛先ごとに配信を絞れる柔軟さも強みです。AWS上でイベント連携や通知の基盤を設計・実装したい、既存の密結合な連携をSNSとSQSで組み替えて疎結合にしたい、といった相談はAWSを含むインフラ構築の受託で受け付けています。基盤の設計から権限・監視・コスト設計までを外部に任せたい場合の入口です。

見送るべき場面｜単一キューの処理・複雑なルーティングが要るケース

逆に見送ったほうがよい場面もあります。1件のメッセージを1つのワーカーが順番に取り出して処理したいだけなら、プッシュのSNSは要らず、取り出し型のSQS単体で足ります。無理にSNSを挟むと構成が増えるだけです。また、SaaSやAWS各サービスが出す多様なイベントを、送信元や内容で細かくルーティングし、スキーマを管理しながら多数の宛先へ振り分けたいなら、イベントバスとして設計されたEventBridgeのほうが素直です。SNSのフィルタは属性ベースの単純な振り分けに向く一方、イベントパターンやスキーマレジストリ、SaaS連携が要るならEventBridgeへ寄せます。判断の順序としては、1対多の同報かつ低レイテンシならSNS、単一の非同期処理ならSQS、SaaS/AWSイベントの高度なルーティングならEventBridge、と用途で切り分けるのが堅実です。

よくある質問

SNSのトピック設計や料金など、導入前に迷いやすい点をまとめます。

Amazon SNSとSQSはどう使い分けますか？

SNSはプッシュ型で、1回の発行を複数の宛先へ同時に配るPub/Subです。SQSはプル型で、1件のメッセージを1つのワーカーが取り出して処理するキューです。1対多の同報が要るならSNS、単一の非同期処理を溜めて捌くならSQSが向きます。実務では両者を組み合わせ、SNSで複数のSQSキューへ同報するファンアウト構成がよく使われます。

標準トピックとFIFOトピックはどちらを選べばよいですか？

順序保証と重複排除が業務要件に含まれるかで判断します。含まれないなら、スループットが高く宛先の種類も豊富な標準トピックが素直です。金融取引や在庫の増減のように順序と一意性が壊れると困る経路だけ、SQS FIFOキューと組み合わせるFIFOトピックを選びます。FIFOは割高になりがちなため、一律の採用は避けます。

Amazon SNSの料金はどのくらいですか？

標準トピックのAPIリクエストは月100万件まで無料、超過分は100万件あたり0.50ドルが基本です（2026年7月時点）。配信は宛先別で、HTTP/HTTPSが100万件あたり0.60ドル、Eメールが10万件あたり2.00ドル、モバイルプッシュが100万件あたり0.50ドルが目安です。SMSは宛先国別に別課金で単価が高めです。64KBごとに1リクエストとして数えられます。

SNSでメールを送るのとSESは何が違いますか？

SNSのメールは、トピックの購読者へ届ける簡易なテキスト通知が中心で、運用アラートやシステム通知に向きます。差出人やドメインを整えて顧客へHTMLメールを大量に送るなら、送信に特化したSESが適しています。運用通知はSNSのA2P、顧客向けのメール配信はSES、と役割で分けるのが実務の基本です。

届かなかったメッセージはどうなりますか？

SNSはHTTP/HTTPSやLambda宛の一時的な失敗に自動でリトライをかけます。規定回数内に届かなかったメッセージは、サブスクリプションにデッドレターキュー（SQSキュー）を設定しておくと、そこへ退避され、失われずに残る仕組みです。退避したメッセージは後から原因を調べて再処理でき、通知の取りこぼしを防げます。

関連記事

• AWS SQS・SNS・SESの違いと使い分け｜3サービスの選定基準を比較：SNSを含むメッセージング3サービスの役割差と、どれをいつ選ぶかの判断基準を比較で整理しています。
• Amazon SESとは｜メール送信の仕組み・SMTP/API・サンドボックス解除と料金：顧客向けメール配信をSESへ寄せる際の、送信準備と到達性の作り込みがわかります。
• Amazon EventBridgeとは｜イベント駆動連携の仕組み・料金・実装と採用判断：SaaS/AWSイベントの高度なルーティングが要る場合の、SNSとの使い分けの土台になります。
• AWS Lambdaとは｜仕組み・料金体系とコールドスタート対策・採用判断：SNSを購読して処理を実行する、サーバーレスの購読側を組む際の基礎になります。