例えばECサイトで注文が入ったとき、
在庫確認 → 決済 → メール送信 → 配送手配
を1本の処理でつないでいると、どこか1つが詰まっただけで全体が止まってしまいます。
しかも、処理が終わるまで次のリクエストを受け付けられない、なんてことも起きがちです。
こういう「処理の詰まり」や「連鎖的な障害」を防ぐために使われるのが、Amazon SQS（Amazon Simple Queue Service）です。
SQSはメッセージをいったん「キュー（待ち行列）」に預ける仕組みで、送る側と処理する側を切り離してくれます。
片方が遅くても・止まっても、もう片方は影響を受けずに動き続けられるんです。
この記事では、SQSの基本・料金・Lambdaとの連携、そして最近使いやすくなったLambda処理の一時停止機能との使い分けまで、ざっくり整理していきますね。
そもそも「キュー」って何？
キュー（Queue）とは、日本語で「待ち行列」のこと。
先に入ったものが先に出てくる、FIFO（First In, First Out）の仕組みです。
お店のレジをイメージするとわかりやすいかもしれません。
並んだ順に会計されていく、あの列がまさにキューです。
SQSでは、この「キュー」をAWSのマネージドサービスとして提供しています。
この二つを切り離します。
プロデューサーはキューにメッセージを入れるだけ・コンシューマーは自分のペースで取り出して処理する、という流れになります。
SQSで何ができるの？
SQSの主な機能をまとめてみました。
キューの種類：標準キューとFIFOキュー
SQSには2種類のキューがあります。
| 種類 | 順序保証 | 重複 | スループット | 向いている用途 |
|---|---|---|---|---|
| 標準キュー | なし（おおよそ） | あり得る | ほぼ無制限 | ログ収集・画像変換など |
| FIFOキュー | 厳密に保証 | なし | 最大3,000件/秒 | 決済・在庫管理など順序が重要な処理 |
ざっくりまとめるなら「とにかくたくさん処理したい」なら標準キュー、「順番が崩れたら困る」ならFIFOキューを選ぶイメージでしょうか。
どんなときに使うの？
SQSが特に活躍する場面を考えてみました。
逆に、リアルタイム性が最優先の用途（チャットや株価更新など）には向いていません。
そういった場合はWebSocketやAmazon SNSとの組み合わせなど別のサービスを検討してみてください。
お金はどのくらいかかるの？
SQSの料金は、リクエスト数に応じた従量課金になっています。(2026年4月現在)
| キューの種類 | 無料枠（毎月） | 無料枠超過後 |
|---|---|---|
| 標準キュー | 100万リクエスト | $0.40 / 100万リクエスト |
| FIFOキュー | 100万リクエスト | $0.50 / 100万リクエスト |
もちろん、無料枠も用意されていて、個人開発や学習用途なら、十分使える場合がほとんどです。
なお、1リクエストで送受信できるメッセージの最大サイズは256KBです。
それを超える場合はS3に本体を置いてSQSにはポインタだけ渡す、という設計がよく使われます（Java拡張クライアントライブラリがこれをサポートしています）。
Lambdaと組み合わせるとどう動くの？
SQSはLambdaと非常に相性がよく、実際の現場でもよく使われている組み合わせです。
仕組みはシンプルです。
イベントソースマッピングという設定を作ることで、LambdaがSQSを自動でポーリング（監視）し、メッセージが届いたら関数を呼び出してくれます。
ポーリングの仕組みはAWSが管理してくれるので、自分でポーリングコードを書く必要はありません。
処理の流れはこうなります。
- SQSキューにメッセージが届く
- Lambda がキューをポーリングし、メッセージをバッチで取得する
- Lambda 関数が呼び出され、メッセージを処理する
- 処理成功 → メッセージをキューから削除 / 処理失敗 → 可視性タイムアウト後に再試行
Lambda 側で設定できる主なパラメータも覚えておくと便利かもしれません。
Lambda のイベントソースマッピングを一時停止できるようになった
イベントソースマッピングを一時停止（Disabled）してあとから再開できる機能が使いやすくなっています。
これは、UpdateEventSourceMapping API の Enabled: false を使って、キューにメッセージを貯めたまま処理だけを止めることができる仕組みです。
どんな場面で使えるかというと、こんなシーンが考えられるでしょう。
コンソールからの設定方法
- AWSコンソール で Lambda を開く
- 対象の Lambda 関数を選択 → 「設定」タブ → 「トリガー」を開く
- SQS トリガーを選択し、「編集」をクリック
- 「トリガーを有効化」のチェックを外して保存
- 再開するときは同じ手順でチェックを入れ直す
SQSとLambdaの一時停止、どう使い分ける？
「メッセージ処理を止めたい」という目的は同じでも、SQS側で操作するか、Lambda側で操作するかで少し意味合いが変わります。
| 操作 | 何が止まるか | メッセージはどうなるか | 主な用途 |
|---|---|---|---|
| Lambda のイベントソースマッピングを無効化 | Lambda によるポーリングが止まる | キューに残り続ける（最大14日） | Lambda 関数の更新・後段障害時の保護 |
| SQS のキューへのアクセスをIAMで制限 | 送信側・受信側の両方を止められる | アクセス不可になる | 完全にトラフィックを遮断したいとき |
| SQS のメッセージ保持期間を短くする | 古いメッセージを自動削除できる | 期限切れで削除される | 溜まったゴミメッセージを整理したいとき |
「Lambda だけ止めて、メッセージはキューで待機させておきたい」という場面では、イベントソースマッピングの無効化が一番シンプルな方法ですね。
なお、一時停止中もSQSのキューにメッセージが残っている限り、メッセージの保管コストはかかり続けます。
無料枠の範囲内なら気にしなくていいですが、長期間止める場合は注意してくださいね。
キューで「つながりすぎない」設計ができる
Amazon SQS は、シンプルに見えて、システム設計の考え方を変えてくれるサービスです。
「同期的に処理をつなぐ」から「キューを介して非同期につなぐ」に変えるだけで、片方が止まっても全体が止まらない、スパイクに強い設計が実現できます。
Lambda と組み合わせると、コードを書くだけで非同期のメッセージ処理基盤が作れてしまうのが、AWSらしい魅力のひとつですよね。
まずは無料枠の範囲でキューを作って、Lambdaと連携させてみるのがオススメです。
触ってみると、キューの使いどころが一気にイメージしやすくなるかもしれません。
