0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

SNS入門。1回のpublishが購読者全員に届く仕組みと、SQSとの違い

0
Last updated at Posted at 2026-08-13

対象読者: AWSをこれから触る人。 AWS勉強シリーズの2本目で、今回はAmazon SNSがどういうものかを勉強します。全体の地図は索引記事にあります。

SNSとは何か

Amazon SNS(Simple Notification Service)は、通知の配達網です。「お知らせを1回発行すると、登録してある宛先全員に配られる」という仕組みで、この方式は一般にpub/sub(パブリッシュ・サブスクライブ)と呼ばれます。

登場人物は3つだけです。

用語 意味
トピック お知らせの掲示板。宛先はここにぶら下がる
サブスクリプション(購読) 「このトピックのお知らせを受け取ります」という登録。宛先はSQSキュー、メールアドレス、HTTPエンドポイント、Lambda関数などを選べる
publish(発行) トピックにお知らせを1件投げること。これだけで購読者全員に配られる

SQSとの違い

前回のSQSと混同しやすいので、先に違いを整理します。

SQS(キュー) SNS(通知)
例えると 仕事の待ち行列 一斉放送
1件のメッセージは 誰か1人が取って処理する 購読者全員に配られる
メッセージの保管 取り出されるまで残る 配ったら終わり(基本は保管しない)
使いどころ 重い処理を後ろに回す 1つの出来事を複数のシステムに知らせる

「注文が入った」という1つの出来事を、メール送信係と在庫更新係の両方に知らせたい。こういうときにSQSだけで作ろうとすると、どちらかの係がメッセージを取った時点でもう片方に届きません。そこでSNSの出番になります。

定番の使い方。SNS+SQSのファンアウト構成

実務でいちばんよく出てくるのが、SNSトピックの後ろに複数のSQSキューをぶら下げるファンアウト(扇状に配る)構成です。

                    ┌─→ SQSキュー(メール送信係)
注文システム ─publish→ SNSトピック
                    └─→ SQSキュー(在庫更新係)

発行は1回、届くのは全員。しかも受け取り側はSQSなので、係が一時停止していてもメッセージはキューに溜まって失われません。SNSで配って、SQSで受ける。セットで覚えてください。

使い方

やることは「トピックを作る→購読させる→publishする」の3手です。以下はPython(boto3)での最小の形です。

import boto3

sns = boto3.client("sns", region_name="ap-northeast-1")
sqs = boto3.client("sqs", region_name="ap-northeast-1")

# ① トピックを作る
topic = sns.create_topic(Name="order-events")["TopicArn"]

# ② 受け取り側のキューを購読させる(宛先はキューのARNで指定)
q = sqs.create_queue(QueueName="send-mail")["QueueUrl"]
arn = sqs.get_queue_attributes(
    QueueUrl=q, AttributeNames=["QueueArn"])["Attributes"]["QueueArn"]
sns.subscribe(TopicArn=topic, Protocol="sqs", Endpoint=arn)

# ③ publishする。これだけで購読者全員に届く
sns.publish(TopicArn=topic, Message="注文ID: 1234")

受け取り側は普通にSQSから受信するだけです。ただし1つ注意があります。

import json

msg = sqs.receive_message(QueueUrl=q)["Messages"][0]
body = json.loads(msg["Body"])   # SNS経由のメッセージはJSONの封筒に包まれている
print(body["Message"])           # -> 注文ID: 1234

SNS経由でSQSに届いたメッセージは、既定の設定ではJSONの封筒に包まれています。(Raw message deliveryという購読設定を有効にすると、封筒なしで生の文字列を届けることもできます) 実際に届くBodyはこういう形です(抜粋)。

{
  "Type": "Notification",
  "TopicArn": "arn:aws:sns:ap-northeast-1:123456789012:order-events",
  "Message": "注文ID: 1234",
  "Timestamp": "2026-08-13T22:56:38.953Z"
}

送った文字列は Message キーの中にいます。「publishした文字列と受信したBodyが違う」と混乱したら、まずここを疑ってください。

覚えておく注意点

  • 配ったら終わり。 SQSと違ってSNS自体はメッセージを溜めません。受け取り側が受け損ねると困る用途では、上のファンアウト構成のようにSQSで受けるのが定石です
  • 宛先はSQS以外も選べます。 メールアドレスを購読させれば通知メールに、Lambdaを購読させれば「お知らせが来たら関数を実行」になります
  • 本物のAWSでSNS+SQSを繋ぐ場合は、キュー側に「このトピックからの送信を許可する」アクセスポリシーの設定が必要になります。ローカル実験では省略されがちです。実環境で届かないときの原因は大体これです

まとめ

  • SNSは「1回発行したら購読者全員に配る」一斉放送。SQS(待ち行列)と役割が違う
  • 定番はSNSで配ってSQSで受けるファンアウト構成
  • SQSに届く中身はJSONの封筒入り。Message キーを開ける

次はこのシリーズの学びの土台になるIAM(権限管理)をやる予定です。

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?