対象読者: 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(権限管理)をやる予定です。
参考
- Amazon SNS 公式ドキュメント
- 前回: SQS入門
- シリーズ索引: AWSとは何か