How should the SysOps administrator configure the Auto Scaling policy to improve the response time?
Add several different instance sizes in the launch template. Create an Auto Scaling policy based on the ApproximateNumberOfMessagesVisible metric to select the size of the instance based on the number of messages in the queue.
Create an Auto Scaling policy based on the ApproximateNumberOfMessagesDelayed metric to scale the number of instances based on the number of messages in the queue that have been delayed.
Create a custom metric based on the ASGAverageCPUUtilization metric and the GroupPendingInstances metric from the Auto Scaling group. Modify the application to calculate the metric and post the metric to Amazon CloudWatch once each minute. Create an Auto Scaling policy based on this metric to scale the number of instances.
Create a custom metric based on the ApproximateNumberOfMessagesVisible metric and the number of instances in the InService state in the Auto Scaling group. Modify the application to calculate the metric and post the metric to Amazon CloudWatch once each minute. Create an Auto Scaling policy based on this metric to scale the number of instances.
Explanations:
TheApproximateNumberOfMessagesVisiblemetric indicates the number of messages in the queue, but it does not directly correlate with the processing time or the instance size needed. Selecting the instance size based on this metric may not optimize the processing time effectively.
TheApproximateNumberOfMessagesDelayedmetric shows the number of messages that are delayed in the queue. While this could reflect a backlog, scaling based on delays in processing may not be the most efficient way to address the delay issue, as other factors such as instance performance could be involved.
A custom metric based onASGAverageCPUUtilizationandGroupPendingInstanceswould require modifying the application and adding extra complexity. This approach focuses on CPU utilization and pending instances, but it doesn’t directly address the root cause of the delays, which is the number of messages to be processed.
Creating a custom metric based onApproximateNumberOfMessagesVisible(indicating the number of messages in the queue) and the number of instances in the Auto Scaling group allows the scaling policy to trigger based on the workload demand. This approach ensures scaling is based on queue length and available instances, helping to reduce processing delays.
I estimate that the answer is:
Create a custom metric based on the ApproximateNumberOfMessagesVisible metric and the number of instances in the InService state in the Auto Scaling group. Modify the application to calculate the metric and post the metric to Amazon CloudWatch once each minute. Create an Auto Scaling policy based on this metric to scale the number of instances.