Une entreprise de commerce électronique exécute son application sur AWS. L'application utilise un cluster Amazon Aurora PostgreSQL en mode Multi-AZ pour la base de données. Lors d'une récente campagne promotionnelle, l'application a subi une forte charge de lecture et d'écriture. Les utilisateurs ont rencontré des problèmes de délai d'attente lors de l'accès à l'application. Un architecte de solutions doit rendre l'architecture de l'application plus évolutive et hautement disponible avec le MOINS de temps d'arrêt. Quelle solution répondra à ces exigences ?

L'ajout d'instances de lecture supplémentaires au cluster Aurora permet de distribuer la charge de lecture, améliorant ainsi les performances et la scalabilité de l'application face à une forte demande. La création d'un groupe cible Amazon RDS Proxy pour le cluster Aurora gère efficacement les connexions à la base de données, réduit la surcharge de connexion et améliore la résilience de l'application en cas de basculement, minimisant ainsi les temps d'arrêt. Les autres options sont moins efficaces ou inappropriées. L'utilisation d'EventBridge et Lambda pour surveiller les événements n'améliore pas directement la scalabilité ou la disponibilité. La fonctionnalité de redémarrage sans interruption (ZDR) n'est pas une fonctionnalité standard d'Aurora pour la scalabilité des lectures/écritures. La réplication vers ElastiCache avec DMS est une solution de mise en cache, mais ne résout pas directement la scalabilité des écritures et peut introduire de la complexité.