Une application s'exécutant dans un groupe Auto Scaling traite des éléments d'une file d'attente SQS avec des workers à exécution longue. L'équipe doit être alertée lorsque la file d'attente dépasse la taille attendue. Les journaux de l'application sont envoyés à un outil tiers et l'équipe utilise déjà une rubrique SNS pour les alertes. Quelle approche de surveillance est la plus efficace sur le plan opérationnel ?

L'option correcte est la plus efficace car elle utilise une métrique SQS native, ApproximateNumberOfMessagesVisible, qui représente le nombre de messages prêts à être traités. Une alarme CloudWatch basée sur cette métrique, avec une période d'une heure et un seuil approprié, alertera l'équipe via SNS lorsque la taille de la file d'attente dépasse les attentes, indiquant un potentiel backlog. Les autres options sont moins efficaces : Utiliser ApproximateNumberOfMessagesDelayed n'est pas pertinent car cette métrique concerne les messages retardés, non les messages visibles en attente de traitement. Les solutions basées sur Lambda introduisent une complexité et des coûts supplémentaires pour une fonctionnalité déjà disponible via CloudWatch et les métriques SQS natives. De plus, elles pourraient être moins fiables ou plus difficiles à maintenir.