Amazon SNS入門｜Pub/Sub通知の仕組みとLambda・SQS・Slackとの連携パターン

SNSとは？AWSの通知・メッセージ配信サービス

AWSを使った自動化システムを構築していると、「特定のイベントが発生したら複数の宛先に通知したい」という要件が必ず出てきます。私がX投稿ボットやLambda自動化システムを構築する際にも活用したAmazon SNS（Simple Notification Service）について、実践的に解説します。

SNS（Simple Notification Service）はAWSのマネージドなPub/Sub（発行/購読）型メッセージングサービスです。1つのメッセージを複数の宛先に同時配信できるのが最大の特徴です。

SNSのコアコンセプト：トピックとサブスクリプション

トピック

メッセージの配信チャンネルです。「エラー通知」「デプロイ通知」などの目的別にトピックを作成します。

サブスクリプション

トピックに対して「どこに配信するか」を登録します。1つのトピックに複数のサブスクリプションを設定でき、メッセージが届くと全サブスクライバーに同時配信されます。

主なサブスクリプションエンドポイント：

Email / Email-JSON：メールアドレスへの通知（確認メールが必要）
Lambda：Lambda関数をトリガー
SQS：SQSキューへのメッセージ投入
HTTP/HTTPS：WebhookでSlackなど外部サービスへ通知
SMS：携帯電話へのSMSテキスト送信

SNSの代表的な使い方3パターン

パターン1：CloudWatchアラーム → SNS → メール通知

最もシンプルで現場でよく使われる構成です。EC2のCPU使用率がしきい値を超えたらSNSトピックに通知し、担当者にメールを送ります。設定はCloudWatchのアラーム設定画面からSNSトピックを指定するだけです。

パターン2：SNS → SQS → Lambda（Fan-outパターン）

1つのイベントを複数の処理に並列で渡したいときに使います。SNSトピックに複数のSQSキューをサブスクライブさせ、それぞれのキューに対応するLambdaが独立して処理を実行します。

パターン3：EventBridge → SNS → Slack通知

AWSサービスのイベント（EC2停止・S3バケット変更など）をEventBridgeで受け取り、SNS経由でSlack Webhookに通知します。現場の運用監視でよく使われるパターンです。

SNSとSQSの使い分け

混同しやすいSNSとSQSの違いを整理します。

SNS：プッシュ型。メッセージを即時に複数の宛先へ同時配信。配信後のメッセージは保持しない
SQS：プル型。メッセージをキューに溜めて、受信側が取り出す。再処理・リトライが必要な場合に適している

実際の現場では「通知はSNS、非同期処理のキューはSQS、複雑なワークフローはStep Functions」という使い分けを意識するとアーキテクチャがスッキリします。

SNSのフィルタリング機能

SNSにはメッセージ属性に基づいてサブスクライバーごとに配信を制御する「サブスクリプションフィルタポリシー」があります。たとえば「envがproductionのメッセージだけSREチームのSlackに通知する」といった細かい制御が可能です。大規模なシステムでは必須の機能です。

まとめ：SNSはAWS通知アーキテクチャの中心

Amazon SNSは「1対多」の通知配信を実現するシンプルかつ強力なサービスです。CloudWatchアラーム・EventBridge・Lambdaと組み合わせることで、サーバーレスな運用監視・自動化基盤の中核として機能します。まずはCloudWatch→SNS→メール通知の構成から試してみてください。

SNSとSQSの違い：使い分けの判断基準

AWSの通知・メッセージングサービスとして、SNSと並んでよく使われるのがSQS（Simple Queue Service）です。この2つを正しく使い分けることが設計の基本です。

SNS（Pub/Sub）：1つのメッセージを複数の宛先に同時配信。「通知」の用途。受信側が複数いる場合に適している
SQS（Queue）：メッセージをキューに蓄積し、1つのコンシューマーが処理する。「タスク処理」の用途。処理の非同期化・負荷分散に使う

実際によく使われる構成が「SNS + SQS」のファンアウトパターンです。SNSトピックにSQSキューを複数サブスクライブさせることで、1つのイベントを複数のシステムで独立して処理できます。

LambdaとSNSの連携パターン

Lambda関数をSNSのサブスクライバーとして設定すると、トピックにメッセージが届いた瞬間にLambdaが自動実行されます。私がX（Twitter）への自動投稿システムを構築したときも、このパターンを使いました。

実際の構成例：

EventBridge（スケジュール）→ SNSトピック → Lambda（投稿処理）
CloudWatch Alarm（しきい値超過）→ SNSトピック → Lambda（自動復旧処理）+ Email通知

Lambda + SNSの組み合わせで、サーバーレスな自動化システムを低コストで構築できます。

SlackへのSNS通知を設定する

AWSの監視通知をSlackに送る構成はよく求められます。SNSから直接Slackに送る方法と、Lambda経由で送る方法があります。

推奨構成（Lambda経由）：

SNSトピックを作成
LambdaをサブスクライバーとしてSNSに登録
Lambda関数内でSlack Webhook URLにHTTPSリクエストを送信
メッセージのフォーマットをLambda側で整形する

Lambda経由にする理由は、SNSのメッセージをそのままSlackに送るとJSON形式になってしまい、通知が見づらいためです。Lambda側で整形することで「アラーム名・状態・しきい値」などを見やすい形にできます。

SNSのメッセージフィルタリング

SNSトピックに複数のサブスクライバーがある場合、サブスクリプションフィルターポリシーを使うとサブスクライバーごとにメッセージを絞り込めます。

例：エラーレベルが「CRITICAL」のメッセージはSlackに送り、「WARNING」はメールにのみ送るといった制御が可能です。これにより無駄な通知を減らし、受け取る側の負担を軽減できます。

まとめ：SNSを現場で使うための要点

SNSはPub/Sub型の通知サービス。1対多の配信に最適
SQSとの違いを理解して使い分ける（通知 vs タスク処理）
Lambdaと組み合わせることで柔軟な自動化が実現できる
Slack通知はLambda経由でメッセージを整形してから送る
フィルタリングポリシーで不要な通知を減らす設計を意識する

SNSはシンプルに見えて、設計次第でシステムの柔軟性が大きく変わります。EventBridge・SQS・Lambdaとの組み合わせを含めて理解することで、AWSのサーバーレス設計の幅が広がります。