An application running on EC2 instances in an Auto Scaling group processes a high volume of messages from an Amazon SQS queue. Processing a batch of messages took several hours, and the Auto Scaling group's average CPU utilization did not exceed the threshold of its target-tracking scaling policy. Application logs are sent to Amazon CloudWatch Logs. You need the queue to be processed faster with the least operational overhead. Which option satisfies this requirement?

The correct option leverages CloudWatch metric math to directly calculate the messages per instance, which is a suitable metric for scaling based on queue backlog. This approach is efficient because it uses existing metrics and built-in CloudWatch capabilities, minimizing operational overhead. The SQS ApproximateNumberOfMessagesVisible metric indicates the queue backlog, and GroupInServiceInstances from the Auto Scaling group provides the current instance count. Combining these allows for a direct scaling policy. The incorrect options involve creating custom Lambda functions or complex CloudWatch Logs setups. These introduce additional operational overhead, such as managing Lambda code, execution, and permissions, which goes against the requirement for the "least operational overhead." While they could achieve a similar outcome, they are less efficient than using native CloudWatch metric math for this specific scenario.