AWS SNS
Pub/Subモデルで複数のサブスクライバーにメッセージを同時配信するメッセージングサービス
📢SNS とは
Amazon SNS（Simple Notification Service）は、1つのメッセージを複数の宛先に同時に届けるためのPub/Sub（パブリッシュ/サブスクライブ）型メッセージングサービスです。身近なたとえでいうと「新聞配達」のような仕組みです。出版社（Publisher）が新聞を1部作れば、配達システムが全購読者（Subscriber）の家に届けてくれます。
SNSの中心にあるのがトピック（Topic）です。Publisherはトピックにメッセージを1回送るだけで、SNSがそのトピックに登録されている全Subscriberへ自動配信します。ラジオ局（Topic）が電波を1回発信すれば、チューニングしている全リスナー（Subscriber）に届くイメージです。
SQSとの決定的な違いはプッシュ型である点です。SQSはConsumerがキューをポーリング（引き取り）する「プル型」ですが、SNSはメッセージが来たら即座にSubscriberへ配信します。リアルタイム通知やファンアウト（1対多配信）に最適です。
⭐SNS の特徴
SNSの最大の強みはファンアウト配信です。1つのトピックに複数のSubscriberを登録しておけば、1回のPublishで全員にメッセージが届きます。注文が入ったら、在庫サービス・メール通知・ログ記録の3つに同時配信、といった使い方が典型です。
もう1つの重要な機能がメッセージフィルタリングです。Subscriber側で「注文金額が10,000円以上のメッセージだけ受け取る」といった条件を設定できます。これにより、Subscriber側で不要なメッセージを捨てるロジックを書く必要がなくなります。
SNSにはStandard トピックとFIFO トピックの2種類があります。Standardはほぼ無制限のスループットでベストエフォート順序、FIFOは厳密な順序保証とexactly-once配信を提供します。FIFO SNS → FIFO SQS の組み合わせで、順序保証付きファンアウトも実現可能です。
1回のPublishで登録済みの全Subscriberに同時配信。新サービス追加時はSubscribeするだけで既存コードの変更不要。
Subscriber側でフィルタポリシーを設定し、条件に合うメッセージだけを受信。不要なメッセージの処理コストを削減。
FIFO SNS + FIFO SQS の組み合わせで順序保証付きファンアウトを実現。金融取引のような厳密な順序が必要なユースケースに対応。
📨プッシュ型配信 — SNS は「届けに行く」サービス
メッセージの受け渡しには大きく2つの方式があります。SNS を理解するうえで最も重要なポイントです。
SNS はプッシュ型です。メッセージが届いた瞬間にサブスクライバーに「届けに行く」ので、受信側がポーリング（取りに行く）する必要がありません。LINEの通知のように、送ったらすぐ相手のスマホに届くイメージです。
一方、SQS はプル型です。メッセージはキューに溜まっていて、コンシューマーが「取りに行く」必要があります。郵便受けに手紙が届くので自分で見に行くイメージです。
📋トピックとサブスクリプション — 登録の仕組み
SNS はトピック（Topic）とサブスクリプション（Subscription）の2つで成り立っています。YouTube に例えると、トピックは「チャンネル」、サブスクリプションは「チャンネル登録」です。
トピックにメッセージを Publish すると、そのトピックに Subscribe しているすべてのサブスクライバーにメッセージが届きます。サブスクライバーはいつでも追加・削除でき、Publisher 側のコード変更は不要です。
トピックはメッセージの「中継点」です。ARN（arn:aws:sns:ap-northeast-1:123456:order-events）で一意に識別されます。Publisher はこの ARN 宛にメッセージを送るだけで、誰がメッセージを受け取るかは一切知りません。
トピックに「どのプロトコルで」「どの宛先に」配信するかを登録するものです。1つのトピックに SQS・Lambda・Email など異なるプロトコルを混在して登録でき、最大 1,250万件 まで登録できます。
Email / HTTP の場合、宛先の所有者が確認リンクをクリックするまでサブスクリプションは「Pending」状態です。SQS / Lambda / Kinesis Firehose は IAM ポリシーで権限を付与するだけなので確認不要で即座に有効になります。
🔀Standard トピック vs FIFO トピック
SNS トピックにはStandard（標準）とFIFO（先入れ先出し）の2種類があります。ほとんどのユースケースでは Standard で十分ですが、メッセージの順序が重要な場合や重複配信を防ぎたい場合は FIFO を選びます。
| Standard | FIFO | |
|---|---|---|
| 順序保証 | なし（ベストエフォート） | あり（送信順に配信） |
| 重複配信 | まれに発生する | なし（Exactly-once） |
| スループット | ほぼ無制限 | 300 msg/s（バッチで3,000） |
| サブスクライバー | SQS / Lambda / HTTP / Email / SMS | SQS FIFO キューのみ |
| トピック名 | 任意 | 末尾に .fifo が必須 |
| メッセージグループ | 非対応 | MessageGroupId で順序制御 |
| 重複排除 | 非対応 | MessageDeduplicationId |
| 料金 | $0.50 / 100万リクエスト | $0.50 / 100万リクエスト |
| ユースケース | 通知・アラート・ファンアウト | 金融取引・注文処理・ワークフロー |
通知・アラート・ファンアウトなど、メッセージの順番が前後しても問題ないワークロード。ほとんどのユースケースはこちらです。「注文確認メールが5秒早く届いた」くらいは問題になりません。Lambda や Email にも配信でき、スループット制限もありません。
金融取引・注文処理のように「入金 → 出金」の順番が逆になると困る」ワークロード。重複配信も許されない場面です。ただしサブスクライバーは SQS FIFO キューのみに限定され、スループットも 300 msg/s が上限です。
🔍メッセージフィルタリング
メッセージフィルタリングは、Subscriber側で受け取るメッセージを絞り込む仕組みです。トピックに大量のメッセージが流れていても、各Subscriberは自分に関係のあるメッセージだけを受信できます。たとえば「東京リージョンのエラーだけ通知してほしい」といった条件指定が可能です。
フィルタはフィルタポリシー（Filter Policy）としてサブスクリプションに設定します。メッセージの属性（MessageAttributes）を条件にマッチングし、条件に合致するメッセージだけがそのSubscriberに配信されます。フィルタポリシーがないSubscriberは全メッセージを受信します。
フィルタリングを使わない場合、Subscriber側で「自分に関係ないメッセージを捨てる」ロジックを書く必要があります。フィルタリングを使えばSNS側で選別が完了するため、Subscriber側のコードがシンプルになり、不要なメッセージ処理コスト（Lambda呼び出し回数など）も削減できます。
⚖️SNS vs SQS vs EventBridge
| 項目 | SNS | SQS | EventBridge |
|---|---|---|---|
| パターン | Pub/Sub | Queue | Event Bus |
| 配信方式 | プッシュ(1:N) | プル(1:1) | プッシュ(1:N) |
| 主な用途 | ファンアウト通知 | バッファリング | イベント駆動 |
| 順序保証 | FIFOで可能 | FIFOで可能 | なし |
| フィルタ | 属性ベース | なし | ルールベース(強力) |
| メッセージ保持 | なし | 最大14日 | なし |
📝AWS 認定試験（SAA）レベルの問題
関連コンテンツ
AWS IAM ポリシー評価ロジック
AWSリソースへのアクセスを安全に管理する認証・認可サービス
AWS IAM AssumeRole（STS）
AWSリソースへのアクセスを安全に管理する認証・認可サービス
AWS RDS マルチAZ構成
リレーショナルデータベースの構築・運用を自動化するマネージドサービス
AWS RDS リードレプリカ
リレーショナルデータベースの構築・運用を自動化するマネージドサービス
AWS RDS Proxy
リレーショナルデータベースの構築・運用を自動化するマネージドサービス
AWS RDS バックアップとスナップショット
リレーショナルデータベースの構築・運用を自動化するマネージドサービス