When the backlog per instance reaches the target value, a scale-out event will happen. Because the backlog per instance is already 150 messages (1500 messages / 10 instances), your group scales out, and it scales out by five instances to maintain proportion to the target value. Backlog per instance: To calculate your backlog per instance, start with the ApproximateNumberOfMessages queue attribute to determine the length of the SQS queue (number of messages available for retrieval from the queue). Divide that number by the fleet's running capacity, which for an Auto Scaling group is the number of instances in the InService state, to get the backlog per instance. https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html

C is incorrect as scaling based on the number of "notifications" doesn't make logical sense. This means that both the order collection and fulfilment instances would scale in parallel, but they have clearly said that the collection is processing quickly while the fulfilment is struggling. Therefore, we should scale the pool when there is a backlog building in a respective queue - not just based on the number of incoming requests.

not C as the questions state that only one system is struggling, so C doesnt really solve the problem. D does.

Decoupling with Amazon SQS: By using Amazon SQS queues for order collection and order fulfillment, the system can decouple the components, ensuring that orders are not lost, even during scaling events. Orders are queued up and processed in a reliable and scalable manner. Scalability Based on Queue Backlog: By creating a metric based on the backlog per instance calculation, the system can monitor the workload of each instance in the Auto Scaling groups. This allows for dynamic scaling based on the workload, ensuring that additional instances are launched when the backlog increases and terminated when the backlog decreases. Optimization of AWS Resources: This solution optimizes the utilization of AWS resources by dynamically scaling the Auto Scaling groups based on the actual workload, preventing over-provisioning or under-provisioning of instances. It ensures that the system can handle peak traffic efficiently without incurring unnecessary costs.

D is the most appropriate response base on https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-using-sqs-queue.html

D. Provision two Amazon Simple Queue Service (Amazon SQS) queues: one for order collection and another for order fulfillment. Configure the EC2 instances to poll their respective queue. Create a metric based on a backlog per instance calculation. Scale the Auto Scaling groups based on this metric.

SQS auto-scales by default so I don't think we need to mention it explicitly. Option D should be correct.

A. This approach focuses solely on CPU utilization, which may not accurately reflect the scaling needs of the order collection and fulfillment processes. It does not address the need for decoupling and reliable message processing. B. While this approach incorporates alarms to trigger additional Auto Scaling groups, it lacks the decoupling and reliable message processing provided by using SQS queues. It may lead to inefficient scaling and potential data loss. C. Although using SQS queues is a step in the right direction, scaling solely based on queue notifications may not provide optimal resource utilization. It does not consider the backlog per instance and does not allow for fine-grained control over scaling. Overall, option D, which involves using SQS queues for order collection and fulfillment, creating a metric based on backlog per instance calculation, and scaling the Auto Scaling groups accordingly, is the most suitable solution to address the scaling problems while optimizing resource utilization and ensuring reliable message processing.

C is incorrect. "based on notifications that the queues send" SQS does not send notification

D is not correct because it requires more operational overhead and complexity than option C which is simpler and more cost-effective. It uses the existing queue metrics that are provided by Amazon SQS and does not require creating or publishing any custom metrics. You can use target tracking scaling policies to automatically maintain a desired backlog per instance ratio without having to calculate or monitor it yourself.

Scale based on queue length

answer is D. read question again

The number of instances in your Auto Scaling group can be driven by how long it takes to process a message and the acceptable amount of latency (queue delay). The solution is to use a backlog per instance metric with the target value being the acceptable backlog per instance to maintain.

D is correct

C Need to Auto- Scale Queue of SQS

I think its D as here we are creating new metric to calculate load on each EC2 instance.

I think its D as here we are creating new metric to calculate load on each EC2 instance.