Question

A financial services company runs an order-processing worker fleet on EC2 instances in an Auto Scaling group across three Availability Zones. Workers pull messages from an Amazon SQS standard queue. During a recent AZ impairment, several worker instances became unresponsive but continued to appear healthy to the Auto Scaling group, causing messages to sit unprocessed and SLA breaches. The DevOps team must ensure the fleet automatically detects and replaces workers that are no longer processing messages, while still scaling capacity based on backlog. Which combination of actions BEST meets these requirements?

Accepted Answer

Publish a custom CloudWatch metric from each worker indicating recent successful message processing, use a CloudWatch alarm plus lifecycle hook to trigger instance replacement, and scale on the SQS ApproximateNumberOfMessagesVisible per-instance backlog metric.

Answer

Configure an ELB health check on the Auto Scaling group pointing at an Application Load Balancer, and scale the group on the ALB RequestCount metric.

Answer

Increase the SQS visibility timeout and enable a dead-letter queue so stalled messages are retried, then scale the Auto Scaling group on average CPU utilization.

Answer

Switch the standard queue to a FIFO queue and rely on the default EC2 status checks to replace instances that fail hardware or system reachability checks.