対象読者: 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(権限管理)をやる予定です。

参考