Un média gère un site public d'actualités et de vidéos sur AWS. Le site conserve un index des métadonnées vidéo dans une table Amazon DynamoDB configurée avec une capacité provisionnée, et les fichiers vidéo eux-mêmes résident dans un compartiment Amazon S3. Lors d'un événement à fort trafic, les lectures de la table DynamoDB ont été limitées et les vidéos n'ont pas pu apparaître. Les opérateurs ont temporairement augmenté manuellement la capacité de lecture provisionnée de la table. L'équipe souhaite être alertée avant que la limitation ne se produise à l'avenir. Un sujet Amazon SNS a été créé et l'e-mail des opérateurs y est abonné. Quelle action l'équipe doit-elle entreprendre ensuite pour répondre à cette exigence ?

La bonne réponse consiste à créer une alarme Amazon CloudWatch sur la métrique ConsumedReadCapacityUnits. Cette métrique représente le nombre d'unités de capacité de lecture consommées par la table DynamoDB. En définissant un seuil proche de la capacité de lecture provisionnée, l'équipe sera alertée avant que la table n'atteigne sa limite et ne commence à limiter les requêtes, ce qui permet une intervention proactive. L'intégration avec SNS garantit que les opérateurs reçoivent ces alertes par e-mail. Activer la mise à l'échelle automatique de DynamoDB est une solution pour éviter la limitation, mais la question demande une alerte avant que la limitation ne se produise, et la mise à l'échelle automatique ne fournit pas directement cette alerte préventive sur la consommation. Les règles EventBridge pour les actions de mise à l'échelle sont réactives, pas préventives. Les options impliquant CloudWatch Logs pour THROTTLINGEXCEPTION sont réactives. Ces exceptions se produisent après que la limitation a déjà eu lieu, ce qui ne répond pas à l'exigence d'être alerté avant la limitation. De plus, THROTTLINGEXCEPTION est une erreur côté client ou service, pas une métrique directement disponible pour DynamoDB via CloudWatch Logs sans configuration supplémentaire complexe.