Amazon SQS (Simple Queue Service)

Amazon SQS は、アプリケーション間でメッセージを非同期に受け渡すためのマネージドなキューサービスです。 送信側と処理側を直接つなげず、キューを間に置くことで、処理の遅延、負荷の急増、一時的な障害に強いアーキテクチャを作れます。

SAA では、SQS を「メッセージをためるサービス」としてだけ覚えるのではなく、Standard キューと FIFO キュー、可視性タイムアウト、デッドレターキュー、ロングポーリング、Lambda 連携、SNS との使い分けを判断できることが重要です。

Point

• SQS = Simple Queue Service の略です。
• Queue は「待ち行列」という意味です。
• SQS は「処理待ちの仕事をキューにためて、処理側が順番に取り出すサービス」と覚えます。
• 和訳
  • Simple: 単純な、簡単な
  • Queue: 行列、待ち行列
  • Service: サービス
  • Weblio英和辞書「queue」

---

概要

SQS は、分散システムの部品同士を疎結合にするためのサービスです。 たとえば、画像アップロード後のリサイズ処理、注文後の非同期処理、ログ処理、バッチ処理、ワーカーへのジョブ配布などで使います。

送信側はメッセージをキューへ送るだけで処理を完了できます。 処理側は自分のペースでキューからメッセージを取得して処理します。 そのため、処理側が一時的に遅くなっても、送信側のアプリケーション全体を止めずに済みます。

SAA では、「同期処理か非同期処理か」「順序が必要か」「重複処理に耐えられるか」「失敗メッセージをどう隔離するか」「Lambda や Auto Scaling とどう連携するか」を判断します。

見るポイント	代表的な判断
処理を非同期化したいか	SQS を間に置いて producer と consumer を疎結合にします。
高スループット重視か	Standard キューを選び、重複や順序ずれに備えます。
厳密な順序が必要か	FIFO キューと message group ID を使います。
処理失敗が続くか	Dead-letter queue へ隔離します。
空の受信リクエストを減らしたいか	Long polling を使います。
Lambda で処理したいか	SQS を Lambda event source mapping にします。

---

主要技術

①Standard キューと FIFO キュー

SQS には Standard キューと FIFO キューがあります。 Standard キューは高スループットとスケールを重視する通常の選択肢です。 FIFO キューはメッセージの順序と重複排除を重視する場合に使います。

キュー種別	特徴	向いている用途	試験での判断ポイント
Standard キュー	高スループット、少なくとも 1 回配信、ベストエフォート順序	大量ジョブ、画像処理、ログ処理、バックグラウンド処理	重複処理や順序ずれをアプリ側で許容・対策できる場合に選びます。
FIFO キュー	First-In-First-Out、重複排除、メッセージグループ内順序保証	注文処理、決済順序、状態更新、順序が重要なコマンド	順序が必須で、スループットより整合性を重視する場合に選びます。

Standard キューでは、同じメッセージが複数回配信される可能性があります。 そのため、consumer は同じメッセージを複数回処理しても結果が壊れない冪等な設計にします。 また、送信順序が完全に保証されるわけではないため、順序依存の処理には向きません。

FIFO キューでは、message group ID ごとに順序を保ちます。 同じ message group ID のメッセージは順番に処理されますが、異なる message group ID なら並列処理できます。 順序を保ちたい単位を message group ID で適切に分けることが重要です。

Point

• FIFO = First-In, First-Out の略です。
• 先に入ったものを先に出す、という意味です。
• Idempotent（冪等） は、同じ処理を複数回実行しても結果が変わらない性質です。
• 和訳
  • First: 最初の
  • Out: 外へ
  • Idempotent: 冪等な
  • Weblio英和辞書「idempotent」

⚠️ 頻出: 「大量メッセージを高速に処理し、多少の重複は許容」は Standard キュー、「注文や状態変更を順番通りに処理」は FIFO キューです。

1 件のメッセージの最大サイズは、Standard キューと FIFO キューのどちらも 1 MiB です（2025 年 8 月に 256 KiB から引き上げられました）。 画像や動画のように上限を超えるデータは、本体を S3 に保存し、メッセージにはバケット名とオブジェクトキーだけを入れて受け渡します。 Java と Python 向けの Amazon SQS Extended Client Library は、この受け渡しを自動で行います。

---

②メッセージライフサイクルと可視性タイムアウト

SQS のメッセージは、送信、受信、処理、削除という流れで扱います。 consumer がメッセージを受信しても、メッセージは自動では削除されません。 処理が成功したら consumer が削除する必要があります。

可視性タイムアウトは、consumer が受信したメッセージを一時的に他の consumer から見えなくする時間です。 この時間内に処理して削除すれば、他の consumer は同じメッセージを処理しません。 処理が終わる前に可視性タイムアウトが切れると、メッセージは再び見えるようになり、別の consumer に処理される可能性があります。

設定・状態	意味	判断ポイント
Visibility timeout	受信後に一時的に非表示にする時間	処理時間より短すぎると重複処理が増えます。
ChangeMessageVisibility	処理中に可視性タイムアウトを延長・短縮	長時間処理や処理時間が変動する場合に使います。
In-flight message	受信済みだが削除されていないメッセージ	多すぎる場合は削除漏れ、処理遅延、タイムアウト設計を疑います。
Message retention	キュー内で保持できる期間	期限を過ぎたメッセージは削除されます。

長時間処理では、可視性タイムアウトを処理時間に合わせて設定します。 処理時間が読めない場合は、処理中に ChangeMessageVisibility で延長する設計を検討します。 ただし、長すぎる可視性タイムアウトは失敗時の再試行を遅らせます。

⚠️ 頻出: 「同じメッセージが何度も処理される」場合、consumer の冪等性、可視性タイムアウトの長さ、処理後の DeleteMessage 実行を確認します。

---

③Dead-letter queue と失敗処理

Dead-letter queue は、処理に何度も失敗したメッセージを隔離するためのキューです。 失敗メッセージを本来のキューに戻し続けると、正常なメッセージ処理を妨げたり、同じ失敗を繰り返したりします。 DLQ に移すことで、後から原因調査や再処理ができます。

要素	役割	試験での判断ポイント
Dead-letter queue	失敗メッセージの隔離先	処理不能メッセージを分析しやすくします。
maxReceiveCount	DLQ へ移すまでの受信回数	小さすぎると一時障害でも DLQ に入り、大きすぎると失敗が長引きます。
Redrive	DLQ から再処理する操作	バグ修正後にメッセージを戻して処理できます。
CloudWatch alarm	DLQ への流入監視	障害検知に使います。

DLQ は、元のキューと同じアカウント・リージョンに作成する必要があります。 また、FIFO キューには FIFO の DLQ、Standard キューには Standard の DLQ を組み合わせる設計にします。

DLQ は失敗を隠すための仕組みではありません。 DLQ にメッセージが入ったら、consumer の例外、入力データ、権限、依存先サービス、可視性タイムアウト、再試行回数を調査します。

Point

• DLQ = Dead-letter Queue の略です。
• Dead-letter は、配達できなかった郵便物のような意味です。
• SQS では「何度処理しても失敗するメッセージの隔離先」と覚えます。
• 和訳
  • Dead letter: 配達不能郵便
  • Weblio英和辞書「dead letter」

⚠️ 頻出: 「何度も失敗するメッセージで処理が詰まる」は DLQ を設定します。単に可視性タイムアウトを長くするだけでは、根本的な失敗隔離にはなりません。

---

④ショートポーリング、ロングポーリング、バッチ処理

Consumer は ReceiveMessage でキューからメッセージを取得します。 この取得方式にはショートポーリングとロングポーリングがあります。

ショートポーリングはすぐに応答します。 メッセージがない場合も空の応答が返りやすく、空振りリクエストが増えることがあります。 ロングポーリングは、指定時間までメッセージの到着を待ってから応答するため、空の応答を減らし、コスト効率を上げやすいです。

方式	特徴	向いている場面
Short polling	すぐ応答します。空応答が増えやすいです。	即時応答を優先し、空振りを許容する場合です。
Long polling	最大待機時間までメッセージを待ちます。	空応答と API 呼び出しを減らしたい場合です。
Batch API	複数メッセージをまとめて送受信・削除	高スループットと API コスト削減に役立ちます。

Batch API を使うと、複数メッセージをまとめて送信、受信、削除できます。 大量処理では API 呼び出し回数を減らし、スループットとコストを改善できます。 ただし、バッチ内の一部だけ失敗する可能性があるため、結果を個別に確認する設計が必要です。

⚠️ 頻出: 「空の ReceiveMessage が多くコストが増える」は long polling を使います。「大量メッセージを効率よく処理」は batch API も検討します。

---

⑤Lambda、SNS、EventBridge との連携

SQS は他サービスとの連携でよく使われます。 Lambda でキューを処理する場合、Lambda の event source mapping が SQS をポーリングし、メッセージのバッチを Lambda 関数へ渡します。 処理に成功すると、Lambda がメッセージを削除します。

連携	用途	試験での判断ポイント
SQS + Lambda	非同期ワーカー処理	Lambda がキューをポーリングし、バッチ単位で処理します。
SNS + SQS	ファンアウト + バッファリング	1 つのイベントを複数キューへ配信し、各 consumer が独立処理できます。
EventBridge Pipes	ソースからターゲットへの連携・フィルタ・変換	SQS から別サービスへ送る途中で絞り込みや変換をしたい場合に使います。
Auto Scaling + SQS	ワーカー数の自動調整	キュー深度に応じて EC2/ECS ワーカーを増減します。

Lambda と SQS の連携では、関数コードを冪等にする必要があります。 バッチ内の一部メッセージだけ失敗した場合、部分バッチ応答を使わないと、成功済みメッセージも再試行される可能性があります。 そのため、失敗したメッセージだけを再処理する設計が重要です。

SNS は publish-subscribe 型で、1 つのメッセージを複数の購読先へ配信するサービスです。 SQS はキュー型で、consumer が取り出して処理します。 複数システムへ同じイベントを配り、それぞれが独立して処理したい場合は、SNS topic から複数 SQS queue へ配信する fanout 構成がよく使われます。

Point

• SNS = Simple Notification Service の略です。
• Notification は「通知」という意味です。
• SNS は「複数の相手に知らせる」、SQS は「処理待ちをためる」と分けて覚えます。
• 和訳
  • Notification: 通知
  • Fanout: 扇状に広げること
  • Weblio英和辞書「notification」

⚠️ 頻出: 「1 つのイベントを複数の処理系へ配る」は SNS + SQS、「処理側の負荷を吸収する」は SQS、「Lambda で SQS を処理する」は event source mapping です。

---

⑥セキュリティ、暗号化、監視

SQS へのアクセスは IAM ポリシーとキューポリシーで制御します。 同一アカウント内のアプリケーションには IAM ロールで sqs:SendMessage や sqs:ReceiveMessage を付与します。 クロスアカウントや SNS から SQS へ送信する場合は、キューポリシーで送信元を許可します。

観点	関連機能	判断ポイント
IAM 権限	sqs:SendMessage、sqs:ReceiveMessage、sqs:DeleteMessage	producer と consumer に必要最小限の権限を付けます。
Queue policy	クロスアカウント、SNS 連携	キュー側で送信元や利用者を許可します。
SSE-SQS	SQS 管理キーによる暗号化	シンプルに保存時暗号化したい場合です。
SSE-KMS	KMS キーによる暗号化	鍵管理、監査、権限制御が必要な場合です。
VPC Endpoint	VPC からプライベート接続	インターネットを経由せず SQS API に到達したい場合です。
CloudWatch	キュー深度、古いメッセージ、DLQ 流入	遅延や障害検知に使います。

SQS のサーバー側暗号化は、メッセージ本文を暗号化します。 SSE-KMS を使う場合は、SQS 権限だけでなく KMS キーの利用権限も確認します。 暗号化済みキューでは HTTPS と署名付きリクエストが必要です。

監視では、キューに溜まっているメッセージ数、最も古いメッセージの経過時間、処理中メッセージ数、DLQ のメッセージ数を見ます。 キュー深度が増え続ける場合は、consumer 数、処理速度、依存先障害、可視性タイムアウト、スケーリング条件を確認します。

⚠️ 頻出: 「SQS は VPC 内に作るサービス」ではありません。SQS はリージョナルなマネージドサービスです。VPC 内からプライベートにアクセスしたい場合は VPC Endpoint を使います。

---

試験対策

SAA の SQS 問題では、まず「処理を非同期化して疎結合にしたいか」を見ます。 Web リクエスト中に重い処理を直接実行するのではなく、SQS にメッセージを入れて、バックグラウンドの worker や Lambda で処理する構成がよく正答になります。

次に、順序要件を確認します。 順序が不要で高スループットが重要なら Standard キューです。 順序と重複排除が重要なら FIFO キューを選びます。 Standard キューでは at-least-once 配信を前提に、consumer を冪等にします。

問題文のキーワード	優先して考える機能	理由
Producer と consumer を疎結合	SQS	一時的な処理遅延や障害をキューで吸収できます。
大量メッセージを高速処理	Standard キュー	高スループットに向きます。
メッセージ順序が必須	FIFO キュー	Message group ID 内の順序を保てます。
同じメッセージが再処理される	冪等性 + Visibility timeout + DeleteMessage	SQS は重複処理を前提に設計します。
処理に何度も失敗する	Dead-letter queue	失敗メッセージを隔離して調査できます。
空の受信が多い	Long polling	空応答を減らし、コスト効率を改善します。
1 つのイベントを複数処理系へ	SNS + SQS fanout	複数 queue に配信し、各 consumer が独立処理できます。
Lambda でキューを処理	Event source mapping	Lambda が SQS をポーリングして処理します。
キュー深度で worker を増減	Auto Scaling + CloudWatch	backlog に応じて処理能力を調整します。
SQS メッセージを暗号化	SSE-SQS / SSE-KMS	鍵管理要件に応じて選びます。

よくある誤答は、SQS と SNS の混同です。 SQS はキューであり、consumer がメッセージを取り出して処理します。 SNS はトピックであり、複数の購読先に通知を配信します。 複数システムへ同じイベントを確実に届けたい場合は、SNS から複数の SQS キューへ fanout する構成を考えます。

もう一つの頻出ポイントは、SQS が「完全に 1 回だけ処理される」と思い込むことです。 Standard キューは at-least-once 配信で、重複配信の可能性があります。 FIFO キューでも、アプリケーション側のリトライや処理失敗に備えて、冪等性と失敗処理を設計します。

コスト面では、API リクエスト数、メッセージ数、ポーリング方式、KMS 利用、データ転送、Lambda や worker の処理時間が影響します。 SAA では料金の数値暗記より、long polling、batch API、適切な可視性タイムアウト、Auto Scaling による処理能力調整を押さえます。

---

参考文献

• What is Amazon Simple Queue Service?
• Amazon SQS queue types
• Amazon SQS visibility timeout
• Using dead-letter queues in Amazon SQS
• Amazon SQS short and long polling
• Encryption at rest in Amazon SQS
• Using Lambda with Amazon SQS
• AWS Certified Solutions Architect - Associate