Une chaîne d'agences de voyage exécute une application sur deux instances Amazon EC2 fixes derrière un enregistrement multivalue Route 53 qui renvoie les adresses IP élastiques des instances. L'application utilise DynamoDB pour le stockage principal et un cache Redis auto-hébergé. Le contenu des destinations est mis à jour trimestriellement ; les mises à jour provoquent des pics de charge et ont entraîné des temps d'arrêt. Vous devez rendre l'application hautement disponible et capable de gérer la charge de mise à jour. Quelle solution répond à ces besoins ?

La solution correcte répond à tous les besoins. DAX améliore les performances de DynamoDB, réduisant ainsi la latence et la charge sur la base de données, ce qui est crucial pendant les pics. Un groupe Auto Scaling derrière un ALB assure la haute disponibilité et la capacité à gérer les variations de charge en ajoutant ou supprimant automatiquement des instances EC2. La mise à l'échelle planifiée permet de pré-provisionner la capacité avant les mises à jour trimestrielles, évitant ainsi les temps d'arrêt. L'enregistrement Route 53 pointant vers l'ALB assure une résolution DNS fiable. Les options incorrectes ont des lacunes. La deuxième option utilise CloudFront avec un groupe Auto Scaling comme origine, ce qui n'est pas une configuration standard pour une application dynamique nécessitant un équilibreur de charge pour les instances EC2. De plus, la mise à l'échelle manuelle est inefficace. La troisième option propose ElastiCache for Memcached, mais le cache existant est Redis, et DAX est plus adapté pour les performances de DynamoDB. La quatrième option souffre des mêmes problèmes que la deuxième concernant CloudFront et la mise à l'échelle manuelle.