2.1標準
注文確定イベントを、請求、在庫、通知の各サービスへ配信する。
発行側が各サービスの宛先や稼働状態を直接管理しない。
最も適切な設計はどれか。
× 不正解
SNSトピックをイベントの発行点にし、請求・在庫・通知を購読者として分離する。
詳細解説
正しいAmazon SNSトピックへ発行し、各処理サービスがサブスクリプションする
SNSの発行者と複数の購読者を分離し、1イベントを複数の処理へファンアウトできる。
SNSの発行者と複数の購読者を分離し、1イベントを複数の処理へファンアウトできる。
誤り発行サービスが各処理サービスへ順番に同期呼び出しする
購読先の障害や追加が発行処理へ影響し、依存が増える。
購読先の障害や追加が発行処理へ影響し、依存が増える。
誤り各処理サービスが同じデータベースのテーブルを直接監視する
共有データベースへの強い結合とポーリング負荷が生じる。
共有データベースへの強い結合とポーリング負荷が生じる。
誤りすべてのイベントを単一のLambda関数内の分岐へ埋め込む
処理追加や障害分離が難しく、サービス間の独立性を失う。
処理追加や障害分離が難しく、サービス間の独立性を失う。
実際に確かめる
一時的な検証環境で実行できる例です。
Amazon SNSのトピック、発行、サブスクリプションの公式説明を確認する。期待される結果
一つのイベントを複数の購読サービスへ配信するファンアウトを説明できる。理解のポイント
- Amazon SNS
- トピック
- ファンアウト
確認時の注意
- 確認環境: AWS公式SNSドキュメントの確認
- AWS公式SAA-C03 Domain 2と各サービスの公式ドキュメントを確認する。
基礎のおさらい
発行と購読
発行側は購読者の追加や一時停止を意識せず、購読側を独立して拡張できる。
判断のポイント
要件を、疎結合・拡張性・可用性・復旧時間の観点に分けて比較する。
問題IDAWS-SAA-012
確認環境AWS公式SNSドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告