Une application s'exécute sur une seule instance Amazon EC2 lancée par un groupe Auto Scaling (min=1, max=1) dans un sous-réseau privé. L'application utilise une instance de base de données Amazon RDS for MySQL. Le VPC dispose de sous-réseaux dans trois zones de disponibilité, mais une seule passerelle NAT est déployée. L'architecte doit s'assurer que l'application peut fonctionner sur plusieurs zones de disponibilité. Quelle solution répond à cette exigence ?

Pour assurer la haute disponibilité sur plusieurs zones de disponibilité (AZ), chaque AZ doit avoir sa propre passerelle NAT pour la connectivité sortante. La conversion de l'instance RDS en Multi-AZ garantit que la base de données dispose d'un réplica synchrone dans une AZ différente, permettant un basculement automatique en cas de défaillance. Configurer le groupe Auto Scaling pour lancer des instances dans toutes les AZ et augmenter les capacités min et max à 3 assure que l'application s'exécute sur plusieurs instances réparties sur différentes AZ, fournissant ainsi une résilience. Remplacer la passerelle NAT par une passerelle privée virtuelle est incorrect car une passerelle privée virtuelle est utilisée pour la connectivité VPN vers un réseau sur site, pas pour la connectivité Internet sortante. Remplacer la passerelle NAT par une instance NAT est une solution obsolète et moins gérée qu'une passerelle NAT. Activer les sauvegardes automatiques RDS n'assure pas la haute disponibilité en cas de défaillance d'AZ, mais plutôt la récupération de données. Maintenir les capacités min et max du groupe Auto Scaling à 1 ne permet pas d'exécuter l'application sur plusieurs instances simultanément pour la résilience.