Exam SAA-C03 All QuestionsBrowse all questions from this exam
Go to Exam
Question 210

A company offers a food delivery service that is growing rapidly. Because of the growth, the company’s order processing system is experiencing scaling problems during peak traffic hours. The current architecture includes the following:

• A group of Amazon EC2 instances that run in an Amazon EC2 Auto Scaling group to collect orders from the application

• Another group of EC2 instances that run in an Amazon EC2 Auto Scaling group to fulfill orders

The order collection process occurs quickly, but the order fulfillment process can take longer. Data must not be lost because of a scaling event.

A solutions architect must ensure that the order collection process and the order fulfillment process can both scale properly during peak traffic hours. The solution must optimize utilization of the company’s AWS resources.

Which solution meets these requirements?

    Correct Answer: D

    To address the scaling problems during peak traffic hours and ensure reliable message processing while optimizing the utilization of AWS resources, provisioning two Amazon Simple Queue Service (Amazon SQS) queues, one for order collection and another for order fulfillment, is ideal. Configuring the EC2 instances to poll their respective queues enables effective decoupling of the order collection and order fulfillment processes, ensuring data is retained even during scaling events. Creating a metric based on a backlog per instance calculation allows for precise scaling of the Auto Scaling groups. This approach ensures that instances are added or removed based on the actual workload, which optimizes resource utilization and prevents data loss during scaling events. This solution is pragmatic and efficiently addresses both the rapid order collection and the potentially slower order fulfillment process.

Discussion
TungPhamOption: D

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

n43u435b543ht2bOption: D

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.

Guru4CloudOption: D

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.

cookieMrOption: D

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.

studynoplayOption: D

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

mandragonOption: C

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.

pentium75

"You can use target tracking scaling policies" but you don't with option C. What is "scaling based on notifications that the queues send"? Where do they send these notifications to?

JayBee65Option: D

Scale based on queue length

Rudraman

answer is D. read question again

techhbOption: D

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

jatricOption: C

both have their own queue. Instance processing order will be scale up based on the queue length that collect messages that collected by other queue.

lofzeeOption: D

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

UzbekistanOption: D

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.

bujumanOption: D

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

argl1995

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

LuckyAroOption: D

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.

Aseem8888Option: D

D is correct

Rudraman

C Need to Auto- Scale Queue of SQS

JayBee65

Why would you scale based on " Scale the Auto Scaling groups based on notifications that the queues send."? Would it not make 1000 times more sense to scale base don queue length "Create a metric based on a backlog per instance calculation"?