目次
1. 結論
Amazon SNS (Simple Notification Service) は、「システムの伝言板（放送局）」です。あるサービスで起きたことを他の複数のサービスへ「通知」します。送り手と受け手を直接繋がない（疎結合にする）ことで、一方のシステムが故障したり、処理が遅れたりしても、他方に影響を与えない「弾力性」のある構成を可能にします。
2. SAAで出やすいポイント
- パブ/サブモデル: 「パブリッシャー（発行者）」がトピックにメッセージを送り、「サブスクライバー（購読者）」がそれを受け取る。
- ファンアウト (Fan-out): 1つのSNSメッセージを、複数のSQSキュー、Lambda、HTTPエンドポイントなどへ同時にコピーして配信する。
- サーバーレス: 管理・スケーリングはAWSが行うため、非常に高い可用性と耐久性（メッセージは複数のAZに保存される）を持つ。
- メッセージフィルタリング: 購読者ごとに「この条件に合うメッセージだけ送ってほしい」というフィルタを設定可能。
- 多様な配信先: メール(Email)、SMS、モバイルプッシュ通知、Lambda、SQS、Kinesis Data Firehoseなど。
3. キーワードでの判断
| 問題文のキーワード | 疑うべきサービス/機能 | 判断理由 |
|---|---|---|
| 「複数のサービスに同時に通知を送信」 | SNS ファンアウト | 1対多の配信 |
| 「疎結合なアーキテクチャの構築」 | SNS | サービス間の直接依存を排除 |
| 「モバイルデバイスへのプッシュ通知」 | SNS | モバイルプッシュ機能 |
4. ひっかけポイント
- SNS vs SQS:
- SNS: 「プッシュ」型。今すぐ全員に送る。メッセージはすぐ消える（購読者がいないと届かない）。
- SQS: 「プル」型。相手が取りに来るまで貯めておく。メッセージは数日間残る。
- 高スループット: 非常に高いスループットに対応できるが、順序保証が必要な場合は「SNS FIFOトピック」を選択する必要がある。
5. 覚え方
- 「町内放送のスピーカー」。
- 役場（パブリッシャー）が放送（トピック）すると、町中の家（サブスクライバー）に一斉に届く。誰も聞いていなくても放送は流れるし、特定の家だけ放送を切る（フィルタリング）こともできるイメージ。
6. 関連サービス
| サービス名 | 関連する理由 |
|---|---|
| SQS | SNSの後ろにSQSを置く「SNS+SQSファンアウト」はSAAの超頻出構成。 |
| CloudWatch | アラームが発生した際の通知先としてSNSが指定される。 |
| Lambda | SNSイベントをトリガーにカスタムロジック（修復作業など）を実行する。 |
7. Obsidian管理メモ
- 復習ポイント: SNSからSQSへの配信には、SQS側のアクセスポリシーでSNSからの書き込みを許可する必要がある点に注意。
- 関連ノート: メッセージングサービス比較
8. HTMLファイル名
amazon-sns-messaging-and-pub-sub.html
