ある企業のWebアプリは、ユーザーがアップロードした画像をEC2インスタンス群で変換処理しています。アクセスが急増する時間帯に処理が追いつかず、一部のリクエストが失われる問題が起きています。リクエストを失わずに負荷を吸収できる、最も適切な構成はどれですか？

解説

正解は「SQSキューを配置してAuto Scaling」です。なぜSQSが正解かAmazon SQSはメッセージを永続的にバッファリングするため、処理側が一時的に追いつかなくてもリクエストは失われません。メッセージは処理されるまでキューに保持されます（デフォルト4日、最大14日）。さらにキューの深さ（ApproximateNumberOfMessagesVisibleメトリクス）をCloudWatch経由でAuto Scalingのトリガーにすれば、負荷に応じて処理層を自動で伸縮できます。これは疎結合＋バッファリングというAWS設計の王道パターンで、SAA-C03の頻出論点です。他の選択肢がダメな理由SNS: Pub/Sub型のプッシュ配信で、メッセージを長期保持するバッファにはなりません。サブスクライバーが受け取れない場合の再試行はあるものの、負荷吸収の用途にはSQSが適切です。インスタンスの大型化（垂直スケーリング）: 一時的にはしのげても、想定を超えるスパイクで再び溢れます。根本解決になりません。Kinesis Data Streams: リアルタイム分析や順序保証が必要なストリーム処理向けです。単純なジョブの分配とバッファリングにはSQSがシンプルで低コストです。「リクエストを失わない」「負荷を平準化する」というキーワードが出たら、まずSQSを疑いましょう。