Amazon SNS入門｜パブリッシュ/サブスクライブの基礎からFan-outパターン・メッセージフィルタリング・料金まで現場で使える実践ガイド

オンプレ環境で複数システムへの通知基盤を作ろうとすると、送信先ごとに個別の接続コードを書き、配信失敗時のリトライ処理も自前で実装する必要があった。システムが増えるほど配信ロジックは肥大化し、保守コストも膨らんでいく。

Amazon SNS（Simple Notification Service）は、1つの「トピック」にメッセージを発行するだけで複数のエンドポイントへ自動配信するパブリッシュ/サブスクライブ（Pub/Sub）型のフルマネージドサービスだ。メール通知からLambda起動、SQSへの連携まで、幅広い配信先をサポートしている。

この記事では、Amazon SNSの基本概念・Fan-outパターン・メッセージフィルタリング・料金体系を、オンプレ経験者にもわかりやすく解説する。SQSとの違いや使い分けの判断基準についてはAWS SNS vs SQS完全比較の記事もあわせて参照してほしい。

なぜAmazon SNSなのか？（オンプレとの違い・背景）

オンプレ環境での通知処理は、一般的に次のような実装パターンが多かった。

・ジョブ完了 → メール送信スクリプトを直接呼び出す
・複数システムへの通知 → それぞれのAPIエンドポイントへ直接HTTPリクエストを投げる
・非同期処理 → RabbitMQやActiveMQなどのメッセージブローカーを自前管理

このような点対点（Point-to-Point）設計では、通知先が増えるたびに送信側のコードに変更が必要になる。ミドルウェアのクラスター管理・冗長化・バージョンアップも自チームの負担だ。

Amazon SNSのPub/Subモデルでは、送信側（Publisher）はトピックにメッセージを投げるだけでよく、誰が受け取るかを意識しない。受信側（Subscriber）はトピックを購読するだけで、送信側への影響なく追加・変更できる。この疎結合設計が、クラウド時代の通知基盤の主流になっている理由だ。

Amazon SNSの基本概念

1. トピック（Topic）の種類

トピックはメッセージの「配信チャネル」だ。2種類のトピックが存在する。

2. サブスクライバー（Subscriber）の種類

Amazon SNSは多様なエンドポイントをSubscriberとして登録できる。

・Amazon SQS：非同期処理の起点として最も多用される。Fan-outパターンの核心
・AWS Lambda：通知を受けてサーバーレス処理を起動する
・HTTP/HTTPS エンドポイント：外部WebサービスへのリアルタイムWebhook通知
・メール（Email）：運用通知・アラートの受け取り
・SMS：携帯電話番号へのテキストメッセージ配信
・モバイルプッシュ通知：APNs（iOS）・FCM（Android）連携
・Amazon Kinesis Data Firehose：メッセージをS3・Redshift・OpenSearchへ直接ストリーミング

3. メッセージ属性（Message Attributes）

SNSメッセージにはキー/バリュー形式のメタデータを最大10個付与できる。後述のメッセージフィルタリングはこの属性を使って実現する。属性の型はString・Number・Binaryの3種類だ。

基本的な使い方

1. トピックの作成（AWS CLI）

# Standard トピックを作成する（東京リージョン）
aws sns create-topic \
  --name my-notification-topic \
  --region ap-northeast-1

# 出力例
# {
#     "TopicArn": "arn:aws:sns:ap-northeast-1:123456789012:my-notification-topic"
# }

# FIFO トピックを作成する（名前は .fifo で終わる必要がある）
aws sns create-topic \
  --name order-events.fifo \
  --attributes FifoTopic=true,ContentBasedDeduplication=true \
  --region ap-northeast-1

2. サブスクリプションの登録

# SQS キューを Subscriber として登録する
aws sns subscribe \
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:my-notification-topic \
  --protocol sqs \
  --notification-endpoint arn:aws:sqs:ap-northeast-1:123456789012:my-queue \
  --region ap-northeast-1

# Lambda 関数を Subscriber として登録する
aws sns subscribe \
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:my-notification-topic \
  --protocol lambda \
  --notification-endpoint arn:aws:lambda:ap-northeast-1:123456789012:function:my-function \
  --region ap-northeast-1

# メールアドレスを Subscriber として登録する
aws sns subscribe \
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:my-notification-topic \
  --protocol email \
  --notification-endpoint ops-team@example.com \
  --region ap-northeast-1

メール・HTTP/HTTPSエンドポイントのSubscriptionは、登録後に確認メール（またはHTTPリクエスト）が送られる。受信側で確認リンクをクリックするまでは「Pending confirmation」状態となり、メッセージは届かない。確認リクエストの有効期限は3日間なので、本番環境への導入前に必ずテストしておくこと。

3. メッセージの発行（パブリッシュ）

# シンプルなメッセージを発行する
aws sns publish \
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:my-notification-topic \
  --message "バッチ処理が完了しました" \
  --subject "【通知】バッチ完了" \
  --region ap-northeast-1

# メッセージ属性を付与して発行する（フィルタリング用）
aws sns publish \
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:my-notification-topic \
  --message "処理が完了しました" \
  --message-attributes '{
    "event_type": {
      "DataType": "String",
      "StringValue": "order_completed"
    },
    "priority": {
      "DataType": "Number",
      "StringValue": "1"
    }
  }' \
  --region ap-northeast-1

Fan-outパターン：SNS＋SQSで複数コンシューマーへ並列配信

Amazon SNSの最も代表的な活用パターンが「Fan-out（ファンアウト）」だ。1つのトピックに複数のSQSキューを接続し、1回のPublishで複数の独立したワークロードを並列起動できる。

想定例として、ECサイトの「注文完了」イベントを考えてみよう。

注文完了トピック（SNS Standard）
　├── SQS キュー A → 在庫引き当て処理（Lambda）
　├── SQS キュー B → 配送依頼処理（Lambda）
　└── SQS キュー C → 顧客通知メール送信（Lambda）

この設計の利点は次のとおりだ。

・疎結合：各コンシューマー（Lambda）は互いを意識せず独立して開発・デプロイできる
・障害隔離：配送依頼処理が失敗しても、他のキューへの影響はない
・スケーラビリティ：特定のワークロードだけ処理スループットを上げることが容易
・新機能追加の容易さ：新しいSQSキューをSubscriberに追加するだけで、既存コードへの変更は不要

SQSを介することで、AWS Lambdaが直接受け取れないほどの突発的なスパイクをキューで吸収できる点も重要だ。SNSからLambdaへ直接サブスクライブする構成は、Lambda同時実行数の上限に引っかかるリスクがある。高スループットが予想されるシナリオでは、SNS → SQS → Lambda の構成が安全だ。

SQS標準キューとFIFOキューの違い・設計判断については別記事で詳しく解説している。Fan-outパターンで順序が重要な場合は、SNS FIFOとSQS FIFOキューの組み合わせを検討してほしい。

メッセージフィルタリングで不要な通知を排除する

Fan-outパターンで全Subscriberが全メッセージを受け取ると、不要な処理が増えてコストも上がる。Amazon SNSのメッセージフィルタリングを使えば、サブスクリプション単位で「特定の属性を持つメッセージだけ受け取る」ように絞り込める。

フィルタポリシーはJSON形式でサブスクリプションに設定する。

# "order_completed" イベントのみ受け取るフィルタポリシーを設定する
aws sns set-subscription-attributes \
  --subscription-arn arn:aws:sns:ap-northeast-1:123456789012:my-topic:xxxx-xxxx \
  --attribute-name FilterPolicy \
  --attribute-value '{"event_type": ["order_completed"]}' \
  --region ap-northeast-1

# priority が 1 または 2 のメッセージのみ受け取る設定（数値条件）
aws sns set-subscription-attributes \
  --subscription-arn arn:aws:sns:ap-northeast-1:123456789012:my-topic:yyyy-yyyy \
  --attribute-name FilterPolicy \
  --attribute-value '{"priority": [{"numeric": ["<=", 2]}]}' \
  --region ap-northeast-1

# 複数条件の AND 指定
aws sns set-subscription-attributes \
  --subscription-arn arn:aws:sns:ap-northeast-1:123456789012:my-topic:zzzz-zzzz \
  --attribute-name FilterPolicy \
  --attribute-value '{"event_type": ["order_completed", "order_cancelled"], "region": ["jp"]}' \
  --region ap-northeast-1

フィルタポリシーのスコープは2種類ある。

フィルタリングはSNS側で処理されるため、条件に合わないメッセージはSubscriberには届かない。コンソールの「Filtered Out」メトリクスでフィルタリングされたメッセージ数を確認できる。

よくあるつまずき：フィルタポリシーが設定されたサブスクリプションに対して、メッセージ属性なしでPublishすると、そのメッセージはフィルタに一致しないためSubscriberに届かない。SNS Publishの際には対応するメッセージ属性を必ず付与すること。

料金の仕組み（2026年10月時点）

Amazon SNSの料金は主に「APIリクエスト数」と「配信先ごとの単価」で構成される。東京リージョン（ap-northeast-1）の目安を示す。

SQSやLambdaへの配信は比較的安価だ。大量の運用通知をSNSメールで送るより、SNS → SQS → Amazon SES（独自メール配信）の構成のほうがコスト効率が良い場合がある。

メッセージサイズは最大256KBが上限だ。大きなペイロードを送る必要がある場合は、本文にS3のオブジェクトキーを含める参照渡し設計か、SNS Extended Client Libraryを使ったS3経由の配信を検討する。

応用・実務Tips

【重要】Dead Letter Queue（DLQ）で配信失敗を確実にキャッチする

SNSからHTTP/HTTPSエンドポイントやLambdaへの配信が繰り返し失敗した場合、メッセージはデフォルトで廃棄される。本番環境では必ず、SQS DLQをサブスクリプションのRedrivePolicy（再配送ポリシー）に設定しよう。

# Subscription に DLQ を設定する
aws sns set-subscription-attributes \
  --subscription-arn arn:aws:sns:ap-northeast-1:123456789012:my-topic:xxxx-xxxx \
  --attribute-name RedrivePolicy \
  --attribute-value '{"deadLetterTargetArn": "arn:aws:sqs:ap-northeast-1:123456789012:my-dlq"}' \
  --region ap-northeast-1

DLQに滞留したメッセージはCloudWatchアラームで検知する設計が基本だ。配信失敗の原因調査（Lambdaの実行エラー、HTTPエンドポイントの5xx応答など）を速やかに行い、問題修正後にキューから再処理する運用フローを事前に決めておくこと。

クロスアカウント配信の設計

複数のAWSアカウントをまたいだFan-outも実現できる。SNSトピックのリソースポリシーに他アカウントのSubscribe権限を付与すると、別アカウントのSQSキューやLambdaをSubscriberとして登録できる。マルチアカウント環境で共通の通知チャネルを設計する際に有効なパターンだ。

SNS FIFOとEventBridgeの使い分け

順序保証が必要なシナリオではSNS FIFOが有効だが、複雑なルーティングロジックや複数のEventソースを統合したい場合はAmazon EventBridgeのほうが適している。SNS FIFOはSubscriberがSQS FIFOに限定されるため、Lambda直接起動を含む柔軟な構成にはEventBridgeを検討しよう。

モバイルプッシュ通知への拡張

Amazon SNSはAPNs（Apple Push Notification service）とFCM（Firebase Cloud Messaging）のクレデンシャルを直接管理し、モバイルプッシュ通知の配信基盤としても機能する。ただし、プッシュ通知の管理・分析・パーソナライズが重要な要件になる場合は、SNSネイティブ機能だけでは不足することがある。大規模なモバイルアプリ向けには専用の通知管理サービスとの併用も検討すべきだ。

SQSなしでLambdaに直接サブスクライブするときの注意

SNSからLambdaへ直接Subscribeする構成では、SNSが同時に大量のメッセージを配信したとき、Lambda関数が同時実行数の上限（デフォルト1,000）に達する可能性がある。上限に達した場合、余分なメッセージはSNS側でリトライされるが、最終的に配信できなければDLQへ退避する（DLQ未設定の場合は廃棄）。高スループットが想定されるユースケースでは、間にSQSキューを挟む構成が推奨される。

よくあるトラブルと対処法

Subscriptionが「Pending confirmation」のまま解消されない
メール・HTTP/HTTPSエンドポイントのSubscriptionは受信側での確認が必須だ。HTTP/HTTPSエンドポイントの場合、SubscriptionConfirmationタイプのリクエストを受け取り、JSON内の「SubscribeURL」にGETリクエストを返す実装が必要になる。確認リクエストの有効期限は3日間なので、期限内に対応すること。

SQSキューへのメッセージが届かない
SQSキューのアクセスポリシーに、SNSトピックからの「sqs:SendMessage」を許可する設定が必要だ。コンソールからSubscriptionを作成する場合は自動設定されるが、IaCで構築する場合に見落としが多い。SQSキューのリソースポリシーを確認し、該当SNSトピックARNからのSendMessage許可があるかをチェックしよう。

Standard TopicでメッセージがSubscriberに重複して届く
SNS Standard Topicは「少なくとも1回（at-least-once）」の配信を保証するため、重複配信が発生しうる。Subscriber側の処理でメッセージIDを使った冪等性（Idempotency）処理を実装することが原則だ。重複排除が必須のユースケースでは、FIFO TopicとFIFO SQSキューの組み合わせを検討する。

メッセージフィルタリングが期待どおりに動作しない
フィルタポリシーが設定されたサブスクリプションへメッセージ属性なしでPublishすると、どのSubscriberにも届かないことがある。メッセージ属性を付与していても、FilterPolicyScopeの設定（MessageAttributesかMessageBodyか）とフィルタポリシーのスコープが一致していないケースも多い。コンソールのCloudWatchメトリクス「NumberOfNotificationsFilteredOut」でフィルタリング状況を確認しよう。

本記事のまとめ

Amazon SNSは、オンプレのポイント・ツー・ポイント通知設計をPub/Subモデルで置き換え、スケーラブルで疎結合な通知基盤を実現するサービスだ。

Fan-outパターンを使いこなすことで、マイクロサービス間の通知設計を大幅にシンプルにできる。まずはStandard Topicで動作を確認し、順序保証が必要な要件が出てきたらFIFO Topicへの移行を検討するというアプローチが実践的だ。