Application Integration

Amazon SNS

トピックへのpublishを複数の購読者へ配るfan-outのpub/subサービス。AIP-C01では主役にはならず、Guardrailsの介入通知やコスト異常検知のアラート配信といった、周辺の「人に知らせる」役で出てきます。

  • B|実装まわり
  • D2 実装と統合

ひとことで言うと

1つのトピックにpublishすると、登録された複数の購読者(SQS・Lambda・メール・SMS・HTTPSなど)へ同時に配信するpub/subサービスです。AIP-C01ではFM推論そのものに絡む場面は少なく、人間や下流システムへの通知として顔を出します。

要するに、同時放送のアナウンスです。1回の呼びかけ(publish)で、SQSキュー・Lambda・運用担当者のメール・Slack連携用エンドポイントに同時に届きます。EventBridgeが「条件で仕分ける郵便局」なら、SNSは「登録者全員に同じ内容を流す」役割分担です。

なぜ生まれたか

GenAIアプリの運用では、**「機械が自動で処理を続けてよい場面」と「人に知らせて止めるべき場面」**が混在します。SNSは後者の配線としてよく出てきます。

摩擦SNS 側の受け皿
GuardrailsやHITLの介入を複数の担当者・システムに同時に知らせたいトピックへpublish→メール・Lambda・SQSへfan-out
コスト異常検知のアラートを個別に配りたいCost Anomaly Detectionのalert subscriptionはSNSトピックを使う(個別アラートは必須)
同じイベントを本番処理と監査ログ収集の両方に流したい1つのpublishを複数の購読者に複製配信

何に使うか

用途使い方関連ドメイン
Guardrails介入・ポリシー違反の通知Lambdaがpublish→運用チームのメール・チャット連携へD2, D3
コスト異常のアラート配信Cost Anomaly DetectionのSNSトピック購読D4
処理結果のfan-out本番パイプラインと監査/分析パイプラインへ同時配信D2

試験でどう問われるか

問われ方正解に寄る条件引っかけの選択肢
モデル呼び出しコストの急増を個別にすぐ知りたいCost Anomaly Detectionの個別アラート(SNSトピック必須)日次/週次サマリーだけで済ませる(即時性が要件に合わない)
Guardrailsが入力をブロックしたことを複数チームに知らせたいSNSのfan-out(メール+Lambda+SQSへ同時配信)1つの送り先にだけ通知し、他チームは後で確認する運用
同じイベントを本番処理と監査ログの両方に回したい1トピックに複数の購読者を登録同じLambdaを2回呼ぶよう実装する(責務が混ざる)

SNSはFMを呼びません。「エージェントの判断をSNSが下す」ように読める選択肢は誤りです。SNSは配信の複製と到達を担うだけで、判断ロジックはLambdaや上流のGuardrails・Step Functions側にあります。試験でSNSが主役級の選択肢として出たら、まず「これは通知の話か」を疑うのが安全です。

実務でどう使うか

  • SNSは試験のスキル文で名指しされる回数が少ないサービスです。 In-Scopeのサービス一覧には載っていますが、ドメインのスキル文には具体的な使いどころが明記されていません。主役では出ず、「Application Integrationの選択肢の1つ」として他の正解(EventBridge・SQS)の隣に並ぶ形で出ます
  • A2A(Application-to-Application)とA2P(Application-to-Person)の両方を1つのトピックで扱えます。 同じ通知をLambda(機械処理)とメール(人間への通知)に同時に流せるため、「機械的な自動処理」と「人間のエスカレーション」を1つのイベントから分岐させる設計に向きます
  • Cost Anomaly Detectionの個別アラートはSNSトピックが必須です。 日次・週次サマリーはメールだけで完結しますが、即時性が要る運用ではSNSの購読設定を省略できません

SNSは配信を保証しますが、購読者側の処理成否までは面倒を見ません。publishが成功しても、下流のLambdaやHTTPSエンドポイントが処理に失敗すれば、それは購読者側の責任範囲です。重要な通知ほど、購読者側にも再試行・DLQの設計が要ります。

取り違えやすいもの

迷う相手切り分けの一言
EventBridgeSNSは登録済み購読者全員に同じ内容を配るfan-out。EventBridgeはイベントの中身で条件分岐して送り先を変える
Amazon SQSSNSは即時配信のpub/sub。SQSは受け取ったメッセージを溜めて消費者が自分のペースで処理するキュー。SNS→SQSのfan-out構成もよく使われる

想起チェック

Q1. コスト異常検知のアラートを即座に個別で受け取りたい。何が必須?

SNSトピックです。Cost Anomaly Detectionの個別アラート(Individual alerts)は、日次・週次サマリーと違ってSNSトピックへの配信が前提になっています。

Q2. Guardrailsの介入を複数チームに同時に知らせたい。SNSとEventBridge、どちらが単純?

SNSです。条件分岐なしに同じ通知を複数の購読者(メール・Lambda・SQS)へ複製配信するだけなら、ルールを組む必要のあるEventBridgeより単純に済みます。

出典(AWS公式)