Amazon SNS

解決する課題

• 1つのイベントを複数システムへ同報したい
• 送信側は宛先を意識せず疎結合に通知したい
• 障害アラートや通知をメール/SMSで飛ばしたい

主要概念と用語

• トピック: 配信の単位（ここへ publish する）
• サブスクライバー: Lambda / SQS / HTTP(S) / Email / SMS など
• ファンアウト: SNS → 複数のSQS へ同報して並列処理
• フィルタポリシー: 属性で購読者ごとに振り分け
• FIFOトピック: 順序保証が要る場合

仕様・制限・クォータ

• プッシュ型（購読者へ送る）
• トピックへの publish を多数のサブスクライバーへ配信
• 標準/FIFOトピック

内部の仕組み

publishされたメッセージは、トピックに紐づく全サブスクライバーへプッシュされます。ファンアウト（SNS→複数SQS）にすると、各SQSがバッファ・リトライ・DLQを提供するため、処理系を独立にスケールしつつ取りこぼしを防げます。フィルタポリシーで購読者ごとに必要なメッセージだけ受け取らせることも可能です。

設計パターン / ベストプラクティス

• ファンアウト（SNS→複数SQS→各ワーカー）
• フィルタポリシーでトピックを集約しつつ振り分け
• アラート通知（CloudWatchアラーム→SNS→メール/SMS/Chatbot）

運用・監視・トラブルシュート

• 配信失敗はサブスクライバー側のエラー/権限を確認、DLQを設定
• メトリクス: NumberOfMessagesPublished NumberOfNotificationsFailed

コスト

• publish/配信数で課金。SMSは別料金

セキュリティ

• IAM/トピックポリシーでアクセス制御
• 保存時暗号化（KMS）、配信先はHTTPS等

Well-Architected の観点

• 信頼性: 同報＋（SQS併用で）リトライ
• 運用上の優秀性: アラート/イベント連携の標準部品

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# トピック作成 → SQSをサブスクライブ（ファンアウト） → publish
aws sns create-topic --name orders
aws sns subscribe --topic-arn "$TOPIC" --protocol sqs --notification-endpoint "$QUEUE_ARN"
aws sns publish --topic-arn "$TOPIC" --message '{"orderId":"123"}'