はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した SQS / SNS / EventBridge / Amazon MQ 関連の知識をまとめました。
メッセージングサービスの選択は試験で非常に多く問われ、「キューイング vs Pub/Sub」「AWS 独自 API vs プロトコル互換」「Standard vs FIFO」など、複数の判断軸があります。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
メッセージングサービスの使い分け
| サービス | モデル | 用途 | プロトコル互換 |
|---|---|---|---|
| SQS | キューイング（Pull） | デカップリング、バッファリング | AWS 独自 |
| SNS | Pub/Sub（Push） | ファンアウト通知 | AWS 独自 |
| EventBridge | イベントバス（Push） | サードパーティ SaaS 統合 | AWS 独自 |
| Amazon MQ | マネージドブローカー | 既存ブローカー移行 | AMQP/MQTT/STOMP/JMS |
| Kinesis Data Streams | ストリーミング | リアルタイム処理 | AWS 独自 |
判断のポイントです。
- デカップリング / バッファリング → SQS
- ファンアウト通知 → SNS
- サードパーティ SaaS 統合 → EventBridge
- AMQP / MQTT / STOMP 互換 → Amazon MQ
- リアルタイムストリーミング → Kinesis
SQS キュータイプ
| タイプ | 用途 | キーワード |
|---|---|---|
| Standard Queue | 汎用、高スループット、順序保証なし | デフォルト |
| FIFO Queue | 順序保証、重複排除 | exactly-once |
| Temporary Queue | リクエスト-レスポンスパターン | 一時的 |
| Dead-Letter Queue | 処理失敗メッセージの隔離 | デバッグ |
| Delay Queue | メッセージ配信の遅延 | 遅延 |
SQS FIFO 移行のルール
- Standard → FIFO 変換は不可（削除して再作成）
-
.fifoサフィックス必須 - バッチなし: 300 msg/s、バッチあり: 3,000 msg/s
Short Polling vs Long Polling
| Short Polling | Long Polling | |
|---|---|---|
| 動作 | 即座にレスポンス | メッセージが来るまで待機（最大20秒） |
| 空レスポンス | 多い → コスト増 | 少ない → コスト削減 |
| デフォルト | ✅ | ❌（設定必要） |
コスト削減 が求められたら Long Polling を選びましょう。
Kinesis Data Streams vs SQS vs SNS
| サービス | 順序保証 | リアルタイム | 複数コンシューマー |
|---|---|---|---|
| Kinesis Data Streams | ✅（シャード内） | ✅ | ✅（リプレイ可能） |
| SQS Standard | ❌ | △ | ❌ |
| SQS FIFO | ✅ | △ | ❌ |
| SNS | ❌ | ✅ | ✅（ファンアウト） |
Amazon MQ のプロトコル対応
AMQP、MQTT、STOMP、JMS に対応しています。SQS / SNS / Kinesis は AWS 独自 API であり、プロトコル互換はありません。「AMQP 互換」が出たら Amazon MQ です。
EventBridge の特徴
- サードパーティ SaaS と直接統合できる唯一のイベントベースサービス
- 90以上の AWS サービスからイベントを自動取り込み
- JSON 構造のイベントでルールベースフィルタリング
試験で問われる設計パターン
サービス選択系
K8s 移行 + AMQP 互換 → Amazon MQ
シナリオ: オンプレミスの Kubernetes アプリケーションを AWS に移行します。メッセージキューとして AMQP プロトコルが必要です。どのサービスが適切でしょうか？
正解: Amazon MQ
- SQS は AMQP 非対応（AWS 独自 API）
- 自前 RabbitMQ は運用負荷が大きい
MQTT 対応マネージドブローカー → Amazon MQ
シナリオ: IoT デバイスからの MQTT メッセージを受信するマネージドブローカーが必要です。
正解: Amazon MQ
- SQS / SNS / Kinesis は MQTT 非対応
RabbitMQ からの移行 → Amazon MQ
シナリオ: オンプレミスの RabbitMQ を AWS に移行したいです。コード変更は最小限にしたいです。
正解: Amazon MQ
- 既存メッセージブローカーの移行 = Amazon MQ
- SQS / SNS は新規構築向け
SaaS 統合 + 非同期デカップリング → EventBridge
シナリオ: サードパーティ SaaS アプリケーションからのイベントを受け取り、非同期で処理したいです。
正解: Amazon EventBridge
- 「SaaS」「サードパーティ」→ EventBridge
- SNS / SQS はサードパーティ SaaS と直接統合できない
SQS 設計パターン系
非同期画像処理 + リトライ + コスト最小 → SQS + Spot
シナリオ: ユーザーがアップロードした画像を非同期で処理し、失敗時は自動リトライさせたいです。コストを最小限にする構成は？
正解: SQS（非同期バッファ + リトライ）+ EC2 Spot Instances
- SQS + Spot は非同期バッチ処理のコスト最適パターン
- SNS にはキューイング / リトライの仕組みがない
データ急増でメッセージ損失 + バッファリング → SQS
シナリオ: データの急増により処理が追いつかず、メッセージが損失しています。バッファリングで解決するにはどのサービスが適切でしょうか？
正解: SQS キューでバッファリング
- SNS はプッシュ型でポーリング不可
- Firehose はバッチ配信向け
速度の異なるマイクロサービスのデカップリング → SQS
シナリオ: 処理速度が異なる2つのマイクロサービスをデカップリングしたいです。
正解: Amazon SQS
- SQS = ポーリングベースで速度差を吸収
- SNS はプッシュ型（速度差の吸収に不向き）
2段階ジョブ処理のデカップリング → 2つの SQS キュー
シナリオ: 受付処理と後続処理を独立してスケールさせたいです。
正解: 2つの SQS キュー（受付用 + 処理用）+ メッセージ数に基づく ASG スケーリング
- 単一キューでは独立スケールができない
SQS メッセージ処理失敗 → Dead-Letter Queue
シナリオ: SQS のメッセージが何度も処理に失敗しています。失敗したメッセージを隔離して後で調査するにはどうすべきでしょうか？
正解: Dead-Letter Queue（DLQ）
-
maxReceiveCountを超過したメッセージが DLQ に移動 - Long / Short Polling はメッセージの受信方法
リクエスト-レスポンスパターン → SQS Temporary Queues
シナリオ: リクエストに対してレスポンスを返すパターンを SQS で実装したいです。開発時間とコストを削減するには？
正解: SQS Temporary Queues
- 仮想キューを1つの SQS キューに多重化
- FIFO は順序保証用、DLQ は処理失敗用
SQS FIFO 系
SQS Standard → FIFO 移行チェックリスト
シナリオ: SQS Standard キューを FIFO キューに移行する必要があります。正しい手順を3つ選んでください。
正解:
- 既存 Standard キューを削除して FIFO キューとして再作成（変換不可）
-
.fifoサフィックス必須 - バッチありの FIFO スループットは最大 3,000 msg/s
コスト最適化系
SQS コスト削減 → Long Polling
シナリオ: SQS の利用コストを削減したいです。最も効果的な方法はどれでしょうか？
正解: SQS Long Polling
- 空レスポンスを削減 → コスト削減
-
WaitTimeSecondsを 1〜20秒に設定
SQS キュー長に基づく Auto Scaling → Target Tracking + カスタムメトリクス
シナリオ: SQS のキューの深さに応じてワーカーの EC2 をスケールしたいです。
正解: Target Tracking + backlog per instance メトリクス
- Simple Scaling はクールダウンでスパイクに弱い
- Scheduled は突発スパイクに対応不可
統合パターン系
フィードバック収集 + 感情分析 + 1年保持 → API Gateway + SQS + Lambda + Comprehend + DynamoDB TTL
シナリオ: ユーザーのフィードバックを収集し、感情分析して1年間保持したいです。
正解: API Gateway → SQS → Lambda → Comprehend → DynamoDB（TTL 365日）
- SQS がスパイク時のバッファ
- Comprehend = 感情分析
SQS 処理 + 変動トラフィック + コスト + 可用性 → RI + Spot 混合
シナリオ: SQS からメッセージを処理するワーカーを、コスト効率と可用性を両立させて運用したいです。
正解: Reserved Instances（ベースライン）+ ASG with Spot Instances（スパイク）
- Spot のみだと中断リスクで可用性が下がる
- SQS がバッファになるため、Spot 中断時もメッセージは失われない
おわりに
メッセージングサービスの選択は「デカップリング → SQS」「ファンアウト → SNS」「SaaS 統合 → EventBridge」「プロトコル互換 → Amazon MQ」という判断パターンで整理できます。SQS については「Standard vs FIFO」「Long Polling でコスト削減」「DLQ で失敗メッセージ隔離」も頻出なので、しっかり押さえておきましょう。
間違いや補足があればぜひコメントで教えてください。