AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

1. サービス概要

Amazon Simple Notification Service (SNS) は、Pub/Sub（Publish/Subscribe）モデルに基づくフルマネージドのメッセージング・通知サービスです。 Publisherがトピックにメッセージを発行すると、SNSがサブスクライブされている全エンドポイントへPush配信します。 Subscriberが定期的にポーリングする必要はなく、即座に配信されます。

主な用途は、マイクロサービス間の疎結合なイベント伝播、運用アラート通知（CloudWatchアラーム→SNS）、Fan-outパターンによる並列処理、モバイルプッシュ通知です。 SQSと組み合わせたSNS+SQS Fan-outはアーキテクチャパターンとして頻出です。

2. 主な特徴と機能

2.1 トピックの種類

• 標準トピック（Standard）: 高スループット・ベストエフォート順序・重複配信あり。ほぼすべてのサブスクライバータイプに対応。
• FIFOトピック（FIFO）: メッセージグループ単位での厳密な順序保証と重複排除（MessageDeduplicationId/ContentBasedDeduplication）。サブスクライバーはSQS FIFOキューのみ対応。

2.2 サブスクライバーの種類

• SQS（Fan-outに最多利用）、Lambda（サーバーレス処理）
• HTTP/HTTPS（Webhookエンドポイント）
• Eメール / Eメール-JSON: 確認メールによるサブスクリプション確認が必要。
• SMS: 国・キャリアごとに料金が異なる。
• モバイルプッシュ（APNs/FCM/ADM/WNS等）: iOS/Android等への直接プッシュ。
• Amazon Kinesis Data Firehose: S3/Redshift/OpenSearch等へのストリーミング配信。

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

サブスクリプションにフィルタポリシー（Filter Policy）を設定すると、メッセージ属性（Attributes）または本文（Content-based）に基づいて受信するメッセージを選別できます。 1つのトピックで複数種類のイベントを扱いつつ、サブスクライバーごとに必要なイベントのみを受け取ることが可能です。

2.4 Fan-outパターン

1つのSNSトピックに複数のSQSキューをサブスクライブし、メッセージを並列・独立に処理するパターンです。 S3イベント通知は1バケット1宛先しか設定できないため、SNS Fan-out経由で複数のSQSキューや処理に同時配信する構成が一般的です。

2.5 デッドレターキュー（DLQ）と再試行

• HTTPエンドポイントへの配信失敗時に設定可能な再試行バックオフ戦略（即時/線形/指数）。
• DLQ: 配信不能なメッセージをSQSキューへ転送して検査・リドライブ可能。

2.6 メッセージサイズ・形式

メッセージサイズは最大256KB。大きなペイロードには「SNS Extended Client Library」でS3に本体を格納するパターンがあります。

3. アーキテクチャおよび技術要素

1. PublisherがSNSトピック（標準/FIFO）へメッセージをPublishする。
2. SNSはフィルタポリシーを評価し、条件を満たすサブスクライバーへPush配信する。
3. SQSサブスクライバーはキューにメッセージをエンキューし、コンシューマーが非同期に処理する。
4. Lambdaサブスクライバーは受信と同時に関数が起動する。
5. 配信失敗時にリトライ後DLQへ転送する（設定による）。

代表的なパターン: EventBridge/CloudWatch → SNS → SQS×N → Lambda/Worker（Fan-out + 非同期処理分離）。

4. セキュリティと認証・認可

• IAMポリシー: Publish/Subscribe/管理操作のアクセス制御（アイデンティティベース）。
• トピックポリシー（リソースベース）: クロスアカウントのPublish許可や、S3/CloudWatchなどのAWSサービスからのPublishを許可。
• SSE-KMS: トピックに保存されるメッセージをKMSキーで暗号化（転送中はTLS）。
• VPCエンドポイント（PrivateLink）: インターネットを経由せずVPC内からSNSへPublish可能。
• サブスクリプション確認: HTTP/HTTPSおよびEメールは確認フロー（Subscription Confirmation）で意図しない配信を防止。

5. 料金形態

• Publishリクエスト: 100万件あたり料金（最初の100万件は無料枠）。
• SQS/Lambda/SQS FIFO配信: 比較的安価。
• HTTPSエンドポイント: 100万件あたり課金。
• Eメール: 100万件あたり課金（小額）。
• SMS: 送信先の国・メッセージ種別により料金が異なる（Promotional/Transactional）。
• モバイルプッシュ: 100万件あたり課金（非常に安価）。
• SSE-KMS: KMS APIコール分の追加料金。

6. よくあるアーキテクチャ・設計パターン

• Fan-out（SNS+SQS）: SNSトピックに複数のSQSキューをサブスクライブし、同一メッセージを並列処理。S3の単一イベント通知先制約の回避にも利用。
• CloudWatch/EventBridge → SNS → Email/SMS: アラームやイベントを運用担当へリアルタイム通知。
• FIFO保証が必要な場合: SNS FIFOトピック + SQS FIFOキューで順序保証+重複排除。
• クロスアカウント通知: トピックポリシーでクロスアカウントのPublishを許可し、中央監視アカウントへ集約。
• モバイルプッシュ: 各プラットフォーム（APNs/FCM）のApplication ARNを登録し、エンドポイントに直接Push。

7. 設定・デプロイ手順（ハンズオン例）

1. SNSコンソールで標準トピックを作成する。
2. SQSキューをサブスクライバーとして追加し（ARNを指定）、SQSキューポリシーでSNSからの送信を許可する。
3. Eメールサブスクリプションを作成し、確認メールのリンクをクリックして有効化する。
4. フィルタポリシー（例: {"event-type": ["order_placed"]}）をサブスクリプションに設定する。
5. テストメッセージを属性付きでPublishし、フィルタが正しく機能することを確認する。
6. SSE-KMSを有効化し、KMSキーを指定する。

8. 試験で問われやすいポイント