Une application critique s'exécute sur une seule instance EC2 et utilise un cluster ElastiCache for Redis à nœud unique ainsi qu'une instance de base de données RDS for MariaDB. Chaque composant doit être sain et actif pour que l'application fonctionne. Vous devez reconcevoir l'infrastructure afin qu'elle puisse se remettre automatiquement des pannes avec un temps d'arrêt minimal. Quelle combinaison de modifications devriez-vous implémenter ? (Choisissez-en trois.)

Pour une haute disponibilité de l'application, il faut éliminer les points de défaillance uniques. Placer les instances d'application derrière un Elastic Load Balancer et utiliser un groupe Auto Scaling avec au moins deux instances EC2 assure la résilience de la couche applicative en distribuant le trafic et en remplaçant automatiquement les instances défaillantes. Modifier l'instance RDS pour un déploiement Multi-AZ garantit la disponibilité de la base de données en basculant automatiquement vers une instance de secours dans une autre zone de disponibilité en cas de panne. Créer un groupe de réplication pour ElastiCache for Redis et activer le Multi-AZ assure la haute disponibilité du cache en répliquant les données et en basculant automatiquement en cas de défaillance du nœud primaire. Les options incorrectes sont : Configurer le groupe Auto Scaling EC2 en mode illimité n'est pas une configuration standard et ne garantit pas la haute disponibilité. Créer un réplica en lecture RDS dans la même zone de disponibilité n'offre pas de protection contre les pannes de zone de disponibilité et nécessite une promotion manuelle, ce qui augmente le temps d'arrêt. Configurer ElastiCache for Redis pour qu'il soit géré par un groupe Auto Scaling n'est pas la méthode standard pour la haute disponibilité d'ElastiCache ; les groupes de réplication avec Multi-AZ sont la solution appropriée.