Amazon Simple Notification Service (SNS)

1. サービス概要¶

Amazon Simple Notification Service (SNS) は、Publisher/Subscriber(Pub/Sub)モデルに基づくフルマネージドなメッセージングサービス。
トピックを介してメッセージを受信者（Subscriber）へ配信することで、マイクロサービスや分散アプリケーション間の疎結合化、リアルタイムな通知・イベント通知、アラート通知などを実現する。

主なユースケースとして、

アラート・通知システム(メール、SMS、HTTP エンドポイント)
分散アプリ間連携
イベントドリブンアーキテクチャの中継
モバイルプッシュ通知

などが挙げられる。

2. 主な特徴と機能¶

2.1 トピックとサブスクライバー¶

SNS は「トピック」を中心にメッセージを配信する。Publisher はトピックにメッセージを発行し、Subscriber はトピックにサブスクライブすることでメッセージを受け取る。
サブスクライバーとして、

HTTP(S)エンドポイント
E メール
SMS
SQS キュー
Lambda 関数
モバイルプッシュ通知

など、多彩なエンドポイントが指定可能。

2.2 メッセージ配信方式¶

SNS は Push 型でメッセージを配信する。
つまり Subscriber が Pull する必要なく、トピックに新規メッセージが投稿されると即座にサブスクライバーへ通知される。
冗長性を確保し、送信失敗時には再試行（リトライ）戦略をとる。

2.3 メッセージ属性とフィルタポリシー¶

SNS メッセージには属性を付与でき、Subscriber 側でフィルタポリシーを設定することで受信するメッセージを選別可能。
これにより、1 つのトピックで異なる種類のイベントを扱いつつ、サブスクライバーごとに特定属性のメッセージだけを受け取ることができる。

2.4 メッセージ暗号化とセキュリティ¶

サーバー側暗号化(SSE)を用いて、SNS トピックで転送されるメッセージを AWS KMS キーで暗号化可能。
IAM ポリシーやトピックポリシーを使って、特定アカウント、ロール、IP アドレス範囲からのみ Publish や Subscribe を許可するなど、アクセス制御が可能。

3. アーキテクチャおよび技術要素¶

Publisher がトピックにメッセージを Publish。
SNS はサブスクライバー(HTTP、Lambda、SQS、E メール、SMS 等)へメッセージを Push 配信。
フィルタポリシーにより、属性に応じたメッセージを特定サブスクライバーのみに送付可能。
SSE や IAM/トピックポリシーでセキュリティを強化。

4. セキュリティと認証・認可¶

IAM ポリシー: 誰が SNS トピックに Publish/Subscribe 可能かを制御。
トピックポリシー: バケットポリシー同様、トピックリソースに対するアクセス制御を JSON ポリシーで定義。
SSE-KMS 暗号化: トピックへのメッセージを KMS 鍵で暗号化し、メッセージセキュリティを強化。
VPC エンドポイント（PrivateLink）: パブリックインターネット経由せずに VPC 内から SNS へアクセス可能。

5. 料金形態¶

SNS は主に次の項目で課金される:

Publish リクエスト数: トピックへメッセージを送信する度にリクエストとしてカウント。
配信先ごとの料金: E メールは無料枠あり、SMS はメッセージ数/国別料金、HTTP/HTTPS はリクエスト数など。
フィルタポリシー適用コスト: 通常は追加料金なし。
SSE-KMS 利用: KMS API コールコストが発生する可能性。

6. よくあるアーキテクチャ・設計パターン¶

マイクロサービス間通信: SNS トピック経由で非同期にイベント通知し、SQS や Lambda へ配信して処理を連結。
アラート通知: CloudWatch アラームや EventBridge ルールから SNS へメッセージを送り、E メール/SMS で運用担当へリアルタイム通知。
Fan-out パターン: 1 つのメッセージを複数サブスクライバーへ同時配信して並列処理を促進。
モバイルプッシュ通知: SNS と Mobile Push トピックを使い、iOS/Android 端末へ直接通知配信。

7. 設定・デプロイ手順（ハンズオン例）¶

SNS コンソールで新規トピックを作成（トピック名、アクセス制御設定）。
サブスクリプションを作成（E メールアドレスや SQS キュー ARN などを指定）。
Publish テストメッセージを送信し、サブスクライバーに届くことを確認。
必要に応じて、SSE-KMS 暗号化を有効化し、IAM ロールを割り当ててセキュリティ強化。
フィルタポリシーでサブスクライバー毎に受信メッセージを制御。

8. 試験で問われやすいポイント¶

8.1 トピック、サブスクリプション、エンドポイント¶

Pub/Sub モデル、複数エンドポイントへの同時配信。

8.2 フィルタポリシー¶

メッセージ属性に基づく受信メッセージの選別。

8.3 暗号化とアクセス制御¶

IAM ポリシー、トピックポリシーでのアクセス権限管理。
SSE-KMS でメッセージを暗号化。

8.4 料金モデルとコスト最適化¶

無料枠の活用（E メール通知）、SMS コスト、HTTP(S)配信コストの理解。

8.5 サブスクライバーの種類¶

SQS、Lambda、HTTP(S)、E メール、SMS、Mobile Push など豊富なターゲット。

8.6 冗長性と再試行戦略¶

HTTP エンドポイントへの配信失敗時に一定のリトライ戦略あり。

8.7 他サービスとの統合¶

CloudWatch、EventBridge、S3、Lambda、SQS との連携で分散アーキテクチャを構築。

8.8 試験で頻出となる具体的な問われ方と答え¶

Q: SNS はどのようなモデルでメッセージ配信を行うか？
A: Pub/Sub モデルでトピック経由の非同期メッセージ配信を行う。
Q: フィルタポリシーを使うと何ができるか？
A: メッセージ属性に応じて、サブスクライバーごとに受け取るメッセージを選別可能になる。
Q: SSE-KMS は何に使用するか？
A: SNS トピック上で転送されるメッセージを KMS キーで暗号化するために使用。
Q: サブスクライバーを Lambda にした場合の利点は？
A: メッセージ受信をトリガーにコード実行が可能になり、イベント駆動の処理フローを実現できる。
Q: SNS を用いた Fan-out パターンとは何か？
A: 1 つのメッセージを複数のターゲット（SQS、Lambda、E メールなど）へ同時に配信することで並列処理を実現する手法。