Une entreprise exécute un microservice en tant que fonction AWS Lambda. Le microservice écrit dans une base de données SQL sur site qui ne prend en charge qu'un nombre limité de connexions simultanées. Lorsque le volume d'invocations Lambda augmente, la base de données est submergée et plante, provoquant des temps d'arrêt. L'entreprise dispose d'un lien AWS Direct Connect entre le VPC et le centre de données sur site. L'entreprise souhaite protéger la base de données contre la surcharge. Quelle solution répond à ces exigences ?

La solution correcte utilise Amazon SQS comme tampon pour désynchroniser les invocations Lambda de la base de données sur site, protégeant ainsi cette dernière contre les surcharges. En configurant une limite de concurrence réservée sur la fonction Lambda qui est inférieure au nombre maximal de connexions simultanées de la base de données, on s'assure que Lambda ne dépassera jamais la capacité de la base de données. Les autres options sont moins appropriées. La migration vers Aurora Serverless (option B) est une solution de refactoring majeure plutôt qu'une protection de la base de données existante. RDS Proxy (option C) est conçu pour les bases de données Amazon RDS, pas pour les bases de données sur site. L'utilisation d'Amazon SNS (option D) ne résout pas le problème de la limitation des connexions simultanées, car SNS invoque Lambda directement, et la concurrence provisionnée ne garantit pas la non-surcharge si le nombre de messages est trop élevé.