Customers upload files to S3 and an SQS message containing the object ARN is sent. An EC2-based worker polls SQS and processes files; processing time varies with file size. To reduce customer-perceived delays, an administrator creates an AMI from the existing instance and a launch template. How should Auto Scaling be configured to improve responsiveness?

The correct option directly addresses the problem of varying processing times and the need for responsiveness. By creating a custom metric that divides ApproximateNumberOfMessagesVisible (messages waiting to be processed) by the number of InService instances, the Auto Scaling group can scale based on the actual workload per instance. When this ratio increases, it indicates that each instance has more messages to process, triggering a scale-out. When it decreases, a scale-in can occur. This ensures that the number of worker instances dynamically adjusts to the SQS queue backlog, minimizing customer-perceived delays. Incorrect options: Using different instance sizes with ApproximateNumberOfMessagesVisible alone doesn't account for processing capacity per instance; it just scales based on total messages, not workload per instance. ApproximateNumberOfMessagesDelayed is for messages that have been explicitly delayed, not those waiting to be processed, so it's not relevant for scaling based on current workload. A custom metric based on ASGAverageCPUUtilization and GroupPendingInstances is not directly tied to the SQS queue backlog, which is the primary driver of the workload in this scenario.