Une application SaaS sur AWS utilise AWS Lambda pour le calcul et une base de données Amazon RDS for MySQL Multi-AZ. Lors d'événements de marché à forte demande, le nombre de connexions à la base de données augmente fortement et les utilisateurs subissent des temps de réponse lents. L'entreprise doit améliorer les performances évolutives et la disponibilité de la base de données pour gérer de nombreuses connexions simultanées depuis Lambda. Quelle solution répond à ce besoin ?

La migration vers Amazon Aurora, avec un réplica Aurora, améliore considérablement les performances et la scalabilité par rapport à RDS for MySQL, notamment pour les charges de travail exigeantes. Aurora est conçu pour des performances élevées et une haute disponibilité. L'ajout d'un réplica Aurora permet de décharger les requêtes en lecture de l'instance principale, réduisant ainsi la charge sur la base de données. Amazon RDS Proxy est crucial ici car il gère et met en pool les connexions à la base de données, ce qui est essentiel pour les applications sans serveur comme AWS Lambda, qui ouvrent et ferment fréquemment des connexions. Cela réduit la surcharge de connexion et améliore l'efficacité de la base de données. Les options incorrectes : Ajouter un réplica en lecture via CloudWatch et Lambda est une solution réactive et complexe qui ne résout pas le problème fondamental des connexions excessives et de la surcharge de la base de données principale. La migration vers Aurora avec un réplica en lecture et un pool de connexions initialisé en dehors du gestionnaire Lambda est une amélioration, mais RDS Proxy est une solution plus intégrée et optimisée pour la gestion des connexions Lambda. L'utilisation d'enregistrements pondérés Route 53 distribue le trafic au niveau DNS mais ne gère pas la mise en pool des connexions ni la surcharge des connexions à la base de données.