Auto Scaling グループ内の EC2 インスタンスで実行されているアプリケーションが、Amazon SQS キューからの大量のメッセージを処理します。メッセージのバッチ処理には数時間かかり、Auto Scaling グループの平均 CPU 使用率は、そのターゲット追跡スケーリングポリシーのしきい値を超えませんでした。アプリケーションログは Amazon CloudWatch Logs に送信されます。運用上のオーバーヘッドを最小限に抑えながら、キューをより高速に処理する必要があります。この要件を満たすオプションはどれですか？

正解の選択肢は、運用オーバーヘッドを最小限に抑えながら、キューの処理速度を向上させる最も効率的な方法です。CloudWatch メトリクス数式を使用すると、追加のLambda関数やカスタムメトリクスを発行する手間なく、既存のSQS ApproximateNumberOfMessagesVisible メトリクスとAuto Scalingグループの GroupInServiceInstances メトリクスを直接組み合わせて、インスタンスあたりのメッセージ数を計算できます。この計算されたメトリクスをターゲット追跡スケーリングポリシーのターゲットとして使用することで、キューのバックログに基づいてAuto Scalingグループが動的にスケールアウトし、メッセージ処理を加速できます。 不正解の選択肢は、Lambda関数を作成してカスタムメトリクスを発行する必要があり、運用オーバーヘッドが増加します。また、ログのサブスクリプションフィルターは、メッセージ数ではなくログイベントを処理するため、このユースケースには適していません。