An application running in an Auto Scaling group processes items from an SQS queue with long-running workers. The team needs to be alerted when the queue grows beyond expected size. The application logs are sent to a third-party tool and the team already uses an SNS topic for alerts. Which monitoring approach is most operationally efficient?

The most operationally efficient approach is to use a CloudWatch alarm on the ApproximateNumberOfMessagesVisible metric. This metric directly represents the number of messages available for processing in the queue, which is the core concern for a growing queue. CloudWatch SQS metrics are natively available, requiring no custom setup. An alarm with a 1-hour period and a sum statistic effectively captures sustained queue growth. Notifying an existing SNS topic integrates seamlessly with the team's current alert system. Incorrect options: ApproximateNumberOfMessagesDelayed tracks messages that are not yet visible due to a delay timer, not the overall queue backlog. Creating a Lambda to publish custom metrics adds unnecessary complexity and cost when native metrics suffice. A Lambda directly publishing to SNS bypasses CloudWatch's robust alarming and historical data capabilities.