Question 19
Domain 3: Resilient Cloud SolutionsA company runs an application on an Amazon Elastic Container Service (Amazon ECS) service by using the AWS Fargate launch type. The application consumes messages from an Amazon Simple Queue Service (Amazon SQS) queue. The application can take several minutes to process each message from the queue. When the application processes a message, the application reads a file from an Amazon S3 bucket and processes the data in the file. The application writes the processed output to a second S3 bucket. The company uses Amazon CloudWatch Logs to monitor processing errors and to ensure that the application processes messages successfully. The SQS queue typically receives a low volume of messages. However, occasionally the queue receives higher volumes of messages. A DevOps engineer needs to implement a solution to reduce the processing time of message bursts. Which solution will meet this requirement in the MOST cost-effective way?
Correct answer: A
Explanation
AWS Application Auto Scaling can adjust an ECS service based on demand, and a target tracking policy keeps capacity aligned with the SQS queue size. Because the queue “typically receives a low volume of messages” but “occasionally… higher volumes,” scaling the Fargate service only during bursts reduces processing time without paying for always-on extra tasks.
Why each option is right or wrong
A. Register the ECS service as a scalable target in AWS Application Auto Scaling. Configure a target tracking scaling policy to scale the service in response to the queue size.
Amazon ECS services on Fargate are supported scalable targets under AWS Application Auto Scaling, and target tracking policies can use a CloudWatch metric such as SQS queue depth to adjust the desired task count automatically. Because the queue is usually low-volume but has occasional bursts, scaling out only when the backlog grows reduces the several-minute per-message delay without paying for permanently provisioned Fargate tasks; the service can then scale back in once the queue drains.
B. Increase the maximum number of messages that Amazon SQS requests to batch messages together. Use long polling to minimize the number of API calls to Amazon SQS during periods of low traffic.
Batching and long polling reduce polling overhead, but they do not add processing capacity for bursts.
C. Send messages to an Amazon EventBridge event bus instead of the SQS queue. Replace the ECS service with an EventBridge rule that launches ECS tasks in response to matching events.
EventBridge routes events; it does not replace the need for backlog-based worker scaling here.
D. Create an Auto Scaling group of EC2 instances. Create a capacity provider in the ECS cluster by using the Auto Scaling group. Change the ECS service to use the EC2 launch type.
Switching from Fargate to EC2 adds instance management and is usually less cost-efficient for sporadic bursts.