L'entreprise souhaite un plan de continuité d'activité dans AWS au cas où son application principale sur site (s'exécutant sur des serveurs physiques qui hébergent également d'autres applications) tomberait en panne. L'application utilise MySQL et les systèmes d'exploitation sont compatibles avec EC2. Quelle approche offre la continuité requise avec le moins de surcharge opérationnelle ?

Cette approche utilise AWS Elastic Disaster Recovery (DRS), qui est conçu pour la reprise après sinistre des applications sur site vers AWS avec une surcharge opérationnelle minimale. L'AWS Replication Agent capture les données au niveau du bloc, y compris MySQL, et les réplique vers la région AWS cible. DRS gère automatiquement la conversion des serveurs physiques en instances EC2 compatibles lors d'un basculement, réduisant ainsi la complexité. La capacité d'effectuer des basculements et des retours arrière réguliers garantit la préparation et la validation du plan. Les autres options sont moins optimales : La première option demande une gestion manuelle des instances de test et du basculement, ce qui augmente la surcharge opérationnelle. La troisième option, bien que viable pour la migration de bases de données, est plus complexe pour la réplication complète de serveurs et d'applications, nécessitant la gestion de DMS, SCT et la recréation d'environnements applicatifs. La quatrième option avec Storage Gateway est plus adaptée à la sauvegarde et à la restauration de données, mais pas à une solution de reprise après sinistre complète et rapide pour des applications entières, car elle nécessiterait la reconstruction des serveurs à partir de zéro.