SQS・SNS・SESは名前が似ており、どれを使うべきか判断できないまま設計に入ってしまいがちです。しかしこの3つは、メッセージの受け渡し方（pull型かpush型か）と、宛先が機械か人間かという2軸で切り分けられます。ここでは公式クォータと料金体系を根拠に、選定で本当に効く違いだけを比較します。2025年8月にSQSの最大メッセージサイズが256 KiBから1 MiBへ引き上げられ、SNSは256 KiBのまま据え置かれました。この非対称はファンアウト構成の設計に直接影響します。
まとめ：3サービスの選び分けと判断基準
用途が決まっていれば、選択はほぼ一意に決まります。
- 処理を後回しにして確実に1回さばきたい → SQS。メッセージはキューに滞留し、コンシューマーが取りに行く（pull型）。受け手が落ちていてもメッセージは消えない。
- 1つの出来事を複数の受け手へ同時に配る → SNS。トピックに発行すると購読者へ即座に押し出す（push型）。受け手が応答しなければ再試行のうえ破棄される（サブスクリプションにDLQを設定すればそこへ退避できる）。
- 人間のメールアドレスへメールを届ける → SES。HTML本文・添付・バウンス処理・独自ドメイン送信が必要なメールはすべてSES側の仕事。
迷いやすいのは「SNSでもメールを送れる」点ですが、SNSのEメール配信は1つのEメール購読あたり10通/秒のハード上限があり、引き上げ申請もできません。業務メールをSNSで送る設計は早い段階で頭打ちになります（詳細は後述）。また、SQS単体では複数の受け手に同じメッセージを配れないため、「複数システムへ配りつつ各システムでは確実に処理したい」場合はSNS＋SQSのファンアウトを組みます。
SQS・SNS・SESの違いを一枚で比較
選定に効く軸だけを並べると次のようになります。数値はいずれもAWS公式ドキュメントの既定クォータです（2026年7月時点）。
| 比較軸 | Amazon SQS | Amazon SNS | Amazon SES |
|---|---|---|---|
| モデル | キュー（pull型） | Pub/Sub トピック（push型） | メール送信・受信 |
| 受け手 | 1メッセージを1コンシューマー | 複数サブスクライバーへ同報 | メールアドレス（人間） |
| 宛先の種類 | アプリ／Lambda | SQS／Lambda／HTTP(S)／Eメール／SMS／プッシュ／Firehose | SMTP／SES API |
| 受け手が不在なら | 最大14日まで滞留 | 再試行後に破棄（DLQ設定時は退避） | バウンスとして通知 |
| 最大メッセージ | 1 MiB | 256 KiB | 40 MB（v1 APIは10 MB） |
| 順序保証 | FIFOキューで可 | FIFOトピックで可 | 該当なし |
| 課金単位 | リクエスト（64 KBごと1件） | パブリッシュ数＋配信数 | 通数（0.10USD／1,000通） |
pull型のSQSとpush型のSNS：滞留するかしないかが最大の差
SQSはメッセージをキューに保存し、コンシューマーがReceiveMessageで取りに来るまで待ちます。既定の保持期間は4日、最長14日まで設定でき、処理側がスケールダウンしていても停止していてもメッセージは失われません。ワーカーの処理能力とリクエスト量を切り離す「バッファ」がSQSの本質です。
SNSはトピックへ発行された瞬間に全サブスクライバーへ押し出します。受け手が応答しなければ再試行ポリシーに従ってリトライし、それでも届かなければ破棄されます（サブスクリプションDLQを設定した場合はSQSキューへ退避）。SQSのように何日もキューへ貯めておく機構ではありません。SNS単体は「配る」ことに責任を持ち、「受け切る」ことには責任を持たない。この一点を押さえておけば、両者を混同しなくなります。だからこそ、確実に処理したい受け手はSNSの下にSQSを置きます。なお、Amazon SNS単独の定義・トピックとサブスクリプションの仕組み・ファンアウト・料金はAmazon SNSとはで実装者目線に解説しています。
メッセージサイズの非対称：SQSは1 MiB、SNSは256 KiBのまま
2025年8月、AWSはSQSの最大メッセージペイロードを256 KiBから1 MiBへ引き上げました。標準キュー・FIFOキューの双方が対象で、Lambdaのイベントソースマッピングも1 MiBに追従しています。ただしLambdaの同期呼び出しペイロード上限6 MBは据え置きのため、1 MiBのメッセージを10件バッチで受けることはできません（バッチ合計が6 MBを超えない範囲に実件数が絞られます）。一方でSNSのメッセージ上限は256 KiBのまま据え置かれています。この差は次の節のファンアウト構成で効いてきます。
なお、SQSの課金はリクエスト数ですが、ペイロードは64 KBごとに1リクエストとして数えられます。1 MiBのメッセージ1件は16リクエスト分の課金です。大きなペイロードを送れるようになったこと自体は便利でも、単価は素直に16倍になります。
Amazon SQS：選定時に押さえるべきクォータ
SQSは「非同期処理のバッファ」としてほぼ一択のサービスです。設計時に効く既定値だけ挙げます。
| 項目 | 既定値 | 設定できる範囲 |
|---|---|---|
| 可視性タイムアウト | 30秒 | 0秒〜12時間 |
| メッセージ保持期間 | 4日 | 60秒〜14日 |
| 配信遅延（メッセージタイマー） | 0秒 | 0〜15分 |
| 1バッチのメッセージ数 | — | 最大10件（SQS API） |
| メッセージ属性 | — | 最大10個 |
バッチ10件はSQS API側の上限です。Lambdaのイベントソースマッピング経由で受け取る場合のバッチサイズは標準キューで最大10,000件まで設定できるため、両者を混同しないでください。
可視性タイムアウトは「処理時間の上限」ではなく「独占時間」
コンシューマーがメッセージを受信すると、そのメッセージは可視性タイムアウトの間だけ他のコンシューマーから見えなくなります。既定は30秒。処理が30秒を超えたのに削除しないままだと、メッセージが再びキューに現れて二重処理になります。SQS+Lambda構成についてはAWS公式が「キューの可視性タイムアウトを関数タイムアウトの6倍以上に設定する」と明示しています（バッチウィンドウを使う場合は「6×関数タイムアウト＋MaximumBatchingWindowInSeconds」）。関数タイムアウトが可視性タイムアウトを超える設定はLambda側で検証され、イベントソースマッピングの作成・更新自体がエラーになります。処理時間が読めないジョブでは、処理中にChangeMessageVisibilityで延長します。可視性タイムアウトの決め方やデッドレターキューの設計まで含めたSQS単体の仕様はAmazon SQSとは？標準キューとFIFOの違い・可視性タイムアウトとDLQ設計で個別に整理しています。
また、受信をロングポーリング（WaitTimeSecondsを最大20秒）にすると、空レスポンスを叩き続ける無駄なリクエスト課金を減らせます。既定のショートポーリングのまま高頻度で回すと、メッセージが無くてもリクエストは課金対象です。
標準キューとFIFOキュー：順序を捨てられるか
標準キューはほぼ無制限のスループットを出せますが、順序は保証されず、まれに同じメッセージが2回配信されます（at-least-once）。FIFOキューは順序と重複排除（exactly-once処理）を保証する代わりに、スループットにAPIリクエスト単位の上限があります。ただしFIFOの重複排除が効くのは5分間の重複排除ウィンドウ内に限られ、それを超えて同じ内容が再送されれば別メッセージとして扱われます。料金も標準が100万リクエストあたり0.40USD、FIFOが0.50USDと差があります。無料利用枠は毎月100万リクエストで、これは最初の12か月に限られない恒久的な枠です。
実務では「順序が必要」と言われた要件の大半は、実は冪等な処理設計で吸収できます。FIFOを選ぶ前に、受信側でメッセージIDや業務キーによる重複判定を入れられないかを検討したほうが、スループットの天井を作らずに済みます。順序が本当に不可欠なのは、同一エンティティに対する更新イベントを順番どおりに適用しなければ状態が壊れるケース（在庫の増減、口座残高など）です。
Amazon SNS：トピックを介したPub/Sub配信
SNSの登場人物は3つだけです。メッセージを送るパブリッシャー、それを受け取るサブスクライバー、両者を仲介する論理チャネルであるトピック。パブリッシャーは宛先を知らずにトピックへ発行し、トピックは購読している全員へ配ります。この疎結合があるため、受け手を増減しても発行側のコードは変わりません。
サブスクライバーになれるのは、SQSキュー、Lambda関数、HTTP(S)エンドポイント、Eメール、SMS、モバイルプッシュ、Amazon Data Firehose、および一部のサービスプロバイダー（Datadog、Splunk等）です。
フィルターポリシーで「配ってから捨てる」を避ける
全サブスクライバーに同じメッセージが届くと、受け手側で「自分に関係あるか」を判定して捨てる処理が必要になります。SNSのサブスクリプションフィルターポリシーを使えば、メッセージ属性や本文の値でSNS側が配信可否を判定するため、不要な配信そのものが発生しません。受け手のLambdaが「関係ないイベントだった」で終わる実行にも課金される構成を避けられます。
標準トピックとFIFOトピック：アーカイブとリプレイはFIFOのみ
FIFOトピックは順序保証と重複排除を提供します。順序保証の代償として効いてくるのがメッセージグループあたり300メッセージ/秒という上限です。同じグループIDのメッセージは直列に処理されるため、グループの切り方を誤ると一点集中でスループットが頭打ちになります。FifoThroughputScopeをTopicにすればトピックあたり3,000メッセージ/秒または20 MB/秒（先着）まで引き上げられます。
なおアカウント単位のPublish上限は東京リージョンで標準トピックが1,500メッセージ/秒、FIFOトピックが3,000メッセージ/秒ですが、これはリージョン×アカウント単位のソフトクォータで、緩和申請で引き上げ可能です。設計上の壁になるのは前段のメッセージグループ上限のほうです。
メッセージのアーカイブとリプレイ（ArchivePolicy／ReplayPolicy）が使えるのはFIFOトピックだけで、標準トピックでは利用できません。過去のイベントを再生して新しいコンシューマーを追加したい設計では、この点が選択理由になります。
SNS＋SQSのファンアウト：構成と実効ペイロード上限
「同じイベントを複数システムが受け取り、それぞれ確実に処理する」。最も頻出するこの要件は、SNSトピックにSQSキューを複数サブスクライブすることで解けます。SNSが同報を担い、各SQSキューが受け手ごとの滞留とリトライを担う分業です。片方のシステムが停止していても、そのキューにメッセージが溜まるだけで他システムの処理は止まりません。
アクセスポリシーとraw message delivery：ファンアウトで必ず設定する2点
1つはSQSキューのアクセスポリシーです。SNSトピックからのsqs:SendMessageを、aws:SourceArn条件でそのトピックに限定して許可します。これを忘れると購読は作れても配信が届きません。
もう1つはraw message deliveryの有効化です。既定ではSNSがメッセージ本体をJSONのエンベロープ（Type・MessageId・TopicArn・Message等）で包むため、SQS側ではMessageフィールドを取り出して二重にJSONパースする必要があります。raw message deliveryをオンにすれば発行した本文がそのままキューに入り、受信側のパース処理が1段減ります。
aws sns set-subscription-attributes \
--subscription-arn "arn:aws:sns:ap-northeast-1:123456789012:orders:xxxxxxxx" \
--attribute-name RawMessageDelivery \
--attribute-value trueファンアウトの実効ペイロード上限は1 MiBではなく256 KiB
ここが2025年8月以降の落とし穴です。SQSは1 MiBのメッセージを受けられるようになりましたが、SNS経由で配信する限り、上流のSNSが256 KiBで弾くため実効上限は256 KiBに固定されます。「SQSが1 MiBに対応したから大きなペイロードを流せる」という前提でSNS→SQS構成を設計すると、256 KiBを超えた時点でPublishが失敗します。
大きなペイロードを扱うなら、メッセージ本体をS3に置き、SNSにはS3のキーだけを載せるクレームチェック方式にします。Extended Client Library（SQS版はJavaとPython、SNS版はJava）はまさにこの方式を実装したもので、最大2 GBのペイロードを間接的に扱えます。ペイロードをそのまま押し込む設計は、上限が変わるたびに壊れます。
SNSでメールを送ってはいけない：SESとの決定的な差
SNSはEメールをサブスクライバーに指定できるため、「通知メールはSNSで十分では」と考えたくなります。しかし業務でメールを送るなら、答えははっきりSESです。SNSのEメール配信には次の制約があります。
- 配信レートは1つのEメール購読あたり10通/秒。これはAWSが「引き上げできないハード上限（hard limit and can’t be increased）」と明記しているクォータで、緩和申請ができません。
- 送信できるのはプレーンテキストのみ。HTML本文も添付ファイルも扱えません。
- 受信者が購読確認メールのリンクをクリックしなければ配信が始まりません。エンドユーザー宛の一斉配信には現実的に使えません。
- 送信元アドレスはAWS側のもので、独自ドメインの差出人にはできません。
SNSのEメールが妥当なのは、CloudWatchアラームの通知先のように、開発者数名の固定アドレスへ少量だけ送る運用アラートに限られます。宛先がエンドユーザーになった瞬間、SESへ切り替えるべきと考えて構いません。
SESの送信方式：SMTPとAPIの選び分け
SESには2つの送信経路があります。SES単独の定義・送信元IDの検証・サンドボックス解除・DKIM設定・料金はAmazon SESとはの解説にまとめています。SMTPインターフェースは、既存のアプリケーションやミドルウェアが持つメール送信機能の接続先を差し替えるだけで移行できるのが利点です。SMTP認証情報はIAMのアクセスキーとは別に発行します。もう一方のSES APIはSDK経由で呼び出し、IAM権限でアクセス制御でき、送信結果のレスポンスをその場で扱えます。新規実装ならAPI、既存システムのメール送信基盤を載せ替えるならSMTPという分岐で問題ありません。
新規実装で使うのはSESv2 API のSendEmailです（MIMEを自前で組む場合も同じ操作のRaw content指定で送れます）。旧v1 APIのSendEmail／SendRawEmailは現在も動きますが、1通あたりのメールサイズ上限が10 MBに固定されており、引き上げできません。40 MBまで送れるのはSESv2 APIとSMTPだけです。添付ファイルを扱う要件があるなら、この一点でv2一択になります。
バウンス処理はSNSと組み合わせる
ここでSNSが再登場します。SESのバウンス（宛先不達）や苦情（迷惑メール報告）の通知は、SNSトピック経由で受け取ります。この通知を無視して同じアドレスへ送り続けると、バウンス率が上がり最終的にアカウントの送信が停止されます。SESを導入するなら、バウンス通知用のSNSトピックとその購読先（SQSやLambda）をセットで設計し、無効アドレスを配信リストから外す仕組みまで作ってはじめて運用に載ります。3サービスは競合ではなく、この組み合わせのように役割で噛み合います。
コスト構造の違い：課金の「単位」を間違えない
3サービスは課金の単位が根本的に違うため、単純な単価比較は成立しません。
| サービス | 課金対象 | 公表単価 | 無料枠 |
|---|---|---|---|
| SQS（標準） | リクエスト（64 KBごとに1件） | 0.40USD／100万リクエスト | 毎月100万リクエスト（恒久） |
| SQS（FIFO） | 同上 | 0.50USD／100万リクエスト | 同上 |
| SES（送信） | 通数 | 0.10USD／1,000通 | 新規は12か月間 月3,000メッセージ |
| SES（送信添付データ） | 添付のデータ量 | 0.12USD／GB | — |
| SES（専用IP） | 月額 | 24.95USD／IP | — |
| SES（マネージド専用IP） | 月額＋通数 | 15USD／月＋0.02〜0.08USD／1,000通 | — |
SQSの0.40USDは最初の1,000億リクエストまでの単価で、それを超えると0.30USD、0.24USDへ逓減します。また標準キューでMessageGroupIdを付けてフェアキューを使う場合は、100万リクエストあたり0.10USDの追加課金が発生します。SESのマネージド専用IPは月額15USDに加えて送信量に応じた従量（1,000通あたり0.02〜0.08USD）が乗るため、専用IPの24.95USDより単純に安いとは限りません。
SQSで見落としがちなのが64 KB課金です。リクエスト数だけを見て試算すると、大きめのペイロードを流した瞬間に想定の数倍になります。SNSはパブリッシュ数に加えて宛先種別ごとの配信料が乗る二階建てで、特にSMSは桁が変わるため、料金試算では宛先の内訳を先に確定させてください。この「64 KBごとに1リクエスト」という数え方はEventBridgeにも共通しており、Amazon EventBridgeの料金｜無料になる条件と64KB課金の落とし穴でも同じ落とし穴を扱っています。
EventBridgeとの線引き：SNSと迷ったときの判断
「複数の受け手にイベントを配る」という要件は、SNSでもEventBridgeでも実現できます。両者の分かれ目はルーティングの複雑さと配信レイテンシです。
SNSはトピックという単純なチャネルで、フィルターポリシーによる絞り込みはできても、宛先ごとにイベントの中身を変換したり、AWSサービスのイベントをそのまま受け取ったりはしません。その代わり構成が単純で、配信経路にルール評価が挟まりません。EventBridgeはイベントパターンによる細かいルーティング、入力トランスフォーマーによる整形、AWSサービスやSaaSからのイベント取り込み、スケジュール実行までを担います。1イベントごとにルールの評価と変換が入るぶん、経路としてはSNSより処理段が多くなります。
判断基準はこうです。受け手が固定で「同じものをそのまま配る」ならSNS。イベントの種類が増え続け、宛先ごとに条件と整形が必要ならEventBridge。単純なファンアウトにEventBridgeのルール管理コストを持ち込む必要はありません。SQS・Lambda・EventBridgeを組み合わせた非同期処理の実装と監視の実際は、SQS・Lambda・EventBridgeを用いた非同期処理の実践と運用方法で扱っています。実際にSQSとLambdaで大量データを分割処理する例は、Amazon SQSとAWS Lambdaで実現するCSVファイル一括インポートの最適化が参考になります。
よくある質問
SQSとSNSの違いを一言でいうと？
SQSは受け手が取りに来るまでメッセージを保存するキュー（pull型・原則1つの受け手が処理）、SNSは発行と同時に全購読者へ押し出すトピック（push型・複数の受け手へ同報）です。受け手が不在のとき、SQSは最大14日保持しますが、SNSは再試行のうえ破棄します（DLQを設定すればSQSキューへ退避できます）。
SQSのメッセージサイズ上限は何KBですか？
2025年8月に256 KiBから1 MiB（1,048,576バイト）へ引き上げられ、標準キュー・FIFOキューの両方で1 MiBまで送信できます。ただし課金は64 KBごとに1リクエストとして数えられるため、1 MiBのメッセージ1件は16リクエスト分です。これを超えるペイロードはExtended Client LibraryでS3に退避すれば最大2 GBまで扱えます。
SNSとSESはどちらでメールを送るべきですか？
エンドユーザー宛のメールはSESです。SNSのEメール配信は1つのEメール購読あたり10通/秒という引き上げ不可のハード上限があり、プレーンテキストのみ、受信者の購読確認が必須で、独自ドメインの差出人にもできません。SNSのEメールは、宛先が固定された少数の運用アラート用途に限ります。なおSESで40 MBまでのメールを送れるのはSESv2 APIとSMTPで、旧v1 APIは10 MBが上限です。
SNSとSQSは併用できますか？
できます。SNSトピックにSQSキューをサブスクライブするファンアウト構成が定番で、同報はSNS、確実な処理はSQSが担います。設定時はSQS側のアクセスポリシーでSNSトピックからのsqs:SendMessageを許可し、raw message deliveryを有効にしてJSONの二重パースを避けてください。なお、この構成での実効ペイロード上限はSNS側の256 KiBです。
SQSに無料枠はありますか？
毎月100万リクエストが無料で、これは新規アカウントの12か月限定ではなく恒久的な枠です。超過分は標準キューが100万リクエストあたり0.40USD、FIFOキューが0.50USD。ペイロードは64 KBごとに1リクエストと数えられる点に注意してください。
