How could the Administrator maintain a fast but cost-effective processing time?
Attach an Auto Scaling policy to the Amazon SQS queue to increase the number of EC2 instances based on the depth of the SQS queue
Create an Auto Scaling policy to increase the number of EC2 instances polling the queue and a CloudWatch alarm to scale based on MaxVisibility Timeout
Attach an Auto Scaling policy to the SQS queue to scale instances based on the depth of the dead-letter queue
Create an Auto Scaling policy to increase the number of EC2 instances polling the queue and a CloudWatch alarm to scale based on ApproximateNumberOfMessagesVisible
Explanations:
Amazon SQS does not have Auto Scaling policies. Auto Scaling applies to EC2 instances, not SQS directly.
Scaling based on MaxVisibility Timeout is not a standard metric for Auto Scaling EC2 instances. The appropriate metric is the queue depth (ApproximateNumberOfMessagesVisible).
Auto Scaling policies cannot be directly attached to an SQS dead-letter queue. Scaling should be based on the number of messages in the primary queue.
Scaling EC2 instances based on the number of messages in the SQS queue (ApproximateNumberOfMessagesVisible) is the correct approach to maintain fast and cost-effective processing.
I surmise that the answer is:
Create an Auto Scaling policy to increase the number of EC2 instances polling the queue and a CloudWatch alarm to scale based on ApproximateNumberOfMessagesVisible