SNS・SQS・EventBridgeの違いを初心者向けに解説
AWSのアプリケーション連携サービスであるSNS、SQS、EventBridgeの違い、試験ポイント、実務での使い分けを整理します。
比較対象サービス
サービス名をクリックすると、用語詳細ページで復習できます。
結論
SNS、SQS、EventBridgeは、AWSでシステム同士を連携させるサービスです。
ただし、役割は違います。
| サービス | 一言でいうと | 主な使いどころ |
|---|---|---|
| Amazon SNS | 複数の宛先へ通知を配るサービス | メール通知、Lambda起動、複数システムへの配信 |
| Amazon SQS | メッセージを一時的にためるキュー | 非同期処理、処理待ち、負荷平準化 |
| Amazon EventBridge | イベントに応じて処理を起動するイベントバス | SaaS連携、AWSイベント連携、スケジュール実行 |
迷ったら、まずはこう判断します。
- 通知を複数の宛先へ配りたい：SNS
- 処理を待たせて順番に処理したい：SQS
- イベント条件で処理を振り分けたい：EventBridge
- 定期実行したい：EventBridge
比較表
| 項目 | SNS | SQS | EventBridge |
|---|---|---|---|
| 正式名称 | Amazon Simple Notification Service | Amazon Simple Queue Service | Amazon EventBridge |
| 種類 | Pub/Sub通知 | メッセージキュー | イベントバス |
| 主な目的 | 通知を配信する | メッセージをためる | イベントで処理を起動する |
| 送信先 | 複数の購読者 | キューを読む処理側 | ルールに一致したターゲット |
| メッセージ保持 | 通知中心 | キューに保持 | イベントルーティング中心 |
| 処理方式 | Push型 | Pull型 | ルールベース |
| 代表的な用途 | メール通知、複数Lambda起動 | 非同期ジョブ、処理待ち | 定期実行、イベント連携 |
| 順序制御 | FIFOトピックで対応可能 | FIFOキューで対応可能 | 順序保証目的では使わない |
| このプロジェクトでの用途 | 将来の通知候補 | 将来の非同期処理候補 | 将来の毎日1問配信候補 |
初学者向け説明
Amazon SNS
SNSは、メッセージを複数の宛先へ配る通知サービスです。
1つのトピックにメッセージを送ると、そのトピックを購読しているメール、Lambda、SQSなどに通知できます。
「1つの出来事を複数の相手に知らせたい」ときに使います。
Amazon SQS
SQSは、メッセージを一時的にためるキューです。
処理する側はキューからメッセージを取り出して、順番に処理します。
「今すぐ処理できない仕事を、後で安全に処理したい」ときに使います。
Amazon EventBridge
EventBridgeは、イベントに応じて処理を動かすサービスです。
AWSサービスのイベント、アプリケーションイベント、SaaSイベントなどを受け取り、条件に合うターゲットへ流します。
また、スケジュール実行にも使えます。
このプロジェクトでは、将来的な「毎日1問配信」でEventBridgeを使う候補があります。
試験で問われるポイント
CLF-C02で問われやすいポイント
- SNSは通知配信サービス
- SQSはメッセージキュー
- EventBridgeはイベント駆動の連携サービス
- SQSは疎結合化に役立つ
- SNSは複数の購読者へ通知できる
- EventBridgeはスケジュール実行にも使える
SAA-C03で問われやすいポイント
- 非同期処理で処理待ちを作るならSQS
- 1つのイベントを複数の処理へ配信するならSNS
- AWSサービスやSaaSイベントに応じて処理を起動するならEventBridge
- Lambdaの前段にSQSを置くと、処理の失敗や急増に強くなる
- SNSとSQSを組み合わせると、Fan-out構成を作れる
- EventBridgeはイベントパターンでルーティングできる
実務での使い分け
SNSを選ぶケース
- 1つの通知を複数の宛先へ配信したい
- システム障害通知をメールやLambdaへ送りたい
- 1つのイベントを複数サービスへ配りたい
- SQSと組み合わせてFan-out構成を作りたい
例：
- 注文完了イベントを複数システムへ通知
- CloudWatch Alarmをメール通知
- LambdaとSQSへ同時配信
SQSを選ぶケース
- 非同期処理にしたい
- リクエスト急増時に処理をためたい
- 処理側の失敗時に再試行したい
- Lambdaやワーカーの処理量を制御したい
例：
- 画像変換処理
- メール送信処理
- レポート生成処理
- 外部API呼び出し待ち処理
EventBridgeを選ぶケース
- イベント条件で処理を分岐したい
- AWSサービスの状態変化に反応したい
- SaaSイベントとAWSを連携したい
- 毎日や毎時などのスケジュールでLambdaを起動したい
例：
- 毎朝8時に処理を起動
- S3やEC2のイベントに応じた処理
- 外部SaaSイベントをLambdaへ連携
- 学習サイトで毎日1問を通知
よくある間違い
間違い1：SNSとSQSをどちらも通知サービスとして覚える
SNSは通知を配るサービスです。
SQSはメッセージをためるサービスです。
この違いを押さえると試験で迷いにくくなります。
間違い2：SQSが自動で処理を実行すると思う
SQSはキューです。
メッセージをためますが、処理そのものはLambdaやワーカーが行います。
間違い3：EventBridgeをただのスケジューラーとして覚える
EventBridgeはスケジュール実行にも使えますが、本質はイベント連携です。
イベントパターンに応じてターゲットへルーティングできる点が重要です。
間違い4：全部Lambdaだけで直接つなぐ
小さいシステムでは直接Lambdaを呼ぶ構成でも動きます。
ただし、処理が増えると、SQSやSNSやEventBridgeで疎結合にした方が障害に強くなります。
関連用語
関連問題
まとめ
SNS、SQS、EventBridgeは、システム連携でよく出る重要サービスです。
SNSは通知、SQSはキュー、EventBridgeはイベントルーティングです。
この3つを区別できると、AWSのサーバーレス構成がかなり理解しやすくなります。
次に学ぶ内容
比較で違いを理解したら、関連用語と模擬問題で知識を確認してください。 資格試験では「似ているサービスの使い分け」が問われます。