Une migration lift-and-shift a laissé un groupe Auto Scaling unique où chaque instance EC2 exécute des composants web, de base de données et de cache Redis, ce qui entraîne des temps de réponse variables et des instances surchargées. L'entreprise souhaite séparer les composants pour améliorer la disponibilité et les performances. Quel changement d'architecture satisfera cette exigence ?

La bonne réponse propose une architecture découplée et évolutive. Un Application Load Balancer (ALB) est idéal pour les applications web car il opère au niveau 7 et peut gérer le routage basé sur le contenu. Un groupe Auto Scaling pour l'application web assure l'élasticité et la haute disponibilité. Amazon Aurora avec Multi-AZ offre une base de données relationnelle hautement disponible, performante et gérée. Enfin, un cluster Amazon ElastiCache (Redis OSS) est la solution gérée et évolutive pour le caching, améliorant les performances sans surcharger les instances EC2. Les autres options sont incorrectes car : La première option utilise un Network Load Balancer (NLB) pour l'application web, moins adapté qu'un ALB, et un ALB pour Redis, ce qui est inapproprié car Redis est généralement accédé directement ou via un client. La deuxième option utilise un NLB pour Redis dans une seule zone de disponibilité, ce qui réduit la disponibilité et n'est pas la meilleure pratique pour Redis. La troisième option propose un NLB pour l'application web et tente de pointer un groupe cible vers un nom d'hôte ElastiCache via DNS, ce qui est une configuration complexe et non standard pour ElastiCache.