Amazon SNS

解決する課題

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

主要概念と用語

• トピック: 配信の単位（ここへ publish する）
• サブスクライバー: 標準トピックではLambda / SQS / HTTP(S) / Email / SMS など
• ファンアウト: SNS → 複数のSQS へ同報して並列処理
• フィルタポリシー: 属性で購読者ごとに振り分け
• FIFOトピック: 購読先はSQS標準キューまたはFIFOキュー。LambdaはSQS経由で起動

仕様・制限・クォータ

• プッシュ型（購読者へ送る）
• トピックへの publish を多数のサブスクライバーへ配信
• 標準トピックは多様なプロトコル、FIFOトピックはSQS標準/FIFOキューへ配信

内部の仕組み

publishされたメッセージは、トピックに紐づく対象サブスクライバーへプッシュされます。標準トピックはSQS、Lambda、HTTP(S)、メール、SMSなどへ直接配信できます。FIFOトピックの購読先はSQS標準/FIFOキューだけで、Lambda処理はSQSをイベントソースにします。ファンアウト（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"}'