顧客がファイルを S3 にアップロードすると、オブジェクトの ARN を含む SQS メッセージが送信されます。EC2 ベースのワーカーが SQS をポーリングしてファイルを処理しますが、処理時間はファイルサイズによって異なります。顧客が感じる遅延を減らすため、管理者は既存のインスタンスから AMI と起動テンプレートを作成しました。応答性を向上させるには、Auto Scaling をどのように設定すべきですか？

正解は、キュー内の可視メッセージ数と処理を行うインスタンス数の比率に基づいてスケーリングするカスタムメトリクスを作成することです。これにより、ワークロードの変化に直接対応してインスタンス数を調整し、顧客の遅延を最小限に抑えることができます。 最初の選択肢は、異なるインスタンスサイズを追加するだけでは、ワークロードの変化に動的に対応できません。2番目の選択肢のApproximateNumberOfMessagesDelayedは、メッセージが処理されるまでの遅延を直接示さないため、適切なスケーリング指標ではありません。3番目の選択肢のCPU使用率と保留中のインスタンス数だけでは、SQSキューの負荷を直接反映しないため、最適なスケーリングにはつながりません。