翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon SNS
[Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) では、標準トピックと FIFO トピックの両方を作成できます。トピックは、パブリッシュ/サブスクライブ (pub/sub) アーキテクチャを実装するために使用されます。Amazon SNS は、E メール、SMS (通話料無料番号や 10 桁のロングコードなどの発信元 ID を設定したと仮定)、HTTP(S) エンドポイント、SQS キューなど、さまざまなサブスクリプションタイプをサポートしています。SNS トピックへの E メールメッセージや SMS メッセージなどのエンドユーザーサブスクリプションは、**サブスクライバーが確認する必要があります**。Amazon SNS を使用すると、サービスは広く*ファンアウト*できます。つまり、1 つのメッセージを多数のサブスクライバーに配信できます。SNS 標準トピックのデフォルトのサブスクリプション制限は 1,250 万です。
マイクロサービス環境では、SNS トピックは、メッセージルーティングと配信ロジックをパブリッシャーから切り離すのに役立ちます。これは、トピックフィルターを使用して実装できます。概念的には、トピックフィルターは Amazon EventBridge ルールと多少似ていますが、一元的な場所から利用できるのではなく、サブスクライバーごとに設定されます。例えば、以下があるとします。
+ 注文を処理する注文サービス。
+ 注文受理を処理するフルフィルメントサービス。
+ メンバーに注文にロイヤルティポイントを付与するロイヤルティサービス。
注文に対応する準備ができたら、トピックにメッセージを発行します。フルフィルメントサービスはトピックにサブスクライブしますが、すべての注文について知りたいため、フィルターを適用しません。メンバーの注文時にポイントを付与するロイヤルティサービスがあるとします。ただし、すべての注文がメンバーによって行われるわけではありません。ロイヤルティサービスはトピックをサブスクライブしますが、サブスクリプションフィルターを実装すると、注文がメンバー用かゲスト用かを示す属性を確認できます。
次の図に示すように、システムがエンドユーザーから支払いリクエストを受け取った場合を考えてみましょう。この場合、さまざまなアクションを実行できるように、複数のダウンストリームシステムがリクエストが行われたことを認識する必要があります。Amazon SNS を使用すると、支払いは SNS トピックに発行され、Lambda 関数はトピックをサブスクライブしてカスタマーデータベースとセールスデータベースを更新します。さらに、E メールサブスクリプション (顧客が確認する必要があります) は、サブスクリプションフィルターを使用して E メール確認を顧客に送信します。
## ガイダンス
Amazon SNS についてこのセクションで説明する機能の一部は、EventBridge などのイベントバスによって提供される機能と重複します。次の場合は Amazon SNS の使用を検討してください。
+ トピックには多数のサブスクライバーがいる場合。
+ EventBridge でネイティブにサポートされていないサブスクリプションタイプ (E メールや SMS など) を使用する場合。
+ サブスクライバーは、サブスクリプションフィルターを決定できる必要があります。
+ サブスクライバーへの順序付き配信 (メッセージグループごと) が必要です。
多くのトピックがあり、サブスクリプションとフィルターを使用してマイクロサービス間でメッセージをルーティングしている場合は、EventBridge の方が適しています。