Une entreprise doit concevoir un plan de reprise après sinistre (DR) pour son site web de commerce électronique. Le site s'exécute sur des instances EC2 t3.large au sein d'un groupe Auto Scaling réparti sur plusieurs zones de disponibilité et utilise une instance de base de données Amazon RDS for MySQL. En cas de sinistre, le trafic doit basculer vers une région secondaire. Le RPO cible est de 30 secondes et le RTO est de 10 minutes. Quelle solution répond à ces objectifs de la manière la plus rentable ?

La solution correcte répond aux objectifs RPO (30 secondes) et RTO (10 minutes) de manière rentable. L'utilisation d'un réplica en lecture inter-régions pour RDS MySQL assure un RPO faible pour la base de données. AWS Elastic Disaster Recovery (DRS) réplique en continu les instances EC2, permettant un RPO de quelques secondes et un RTO rapide en lançant de nouvelles instances à partir des données répliquées. Maintenir une capacité minimale dans la région de DR réduit les coûts, et l'augmentation de la capacité lors du basculement gère la charge. L'IaC assure un provisionnement rapide et cohérent. Route 53 avec une politique de basculement permet une transition rapide du trafic. Les autres options sont moins optimales : La première option propose des sauvegardes EC2 via AWS Backup toutes les 30 secondes, ce qui est inefficace et coûteux pour un RPO aussi strict, et la restauration à partir de sauvegardes prendrait plus de 10 minutes (RTO). La troisième option implique une restauration manuelle, ce qui ne respecte pas le RTO de 10 minutes. La quatrième option, bien que techniquement viable pour le RPO/RTO, est la moins rentable car elle maintient le groupe Auto Scaling à pleine capacité dans la région de DR, doublant ainsi les coûts d'infrastructure. De plus, la migration vers Aurora Global Database n'est pas nécessaire car un réplica en lecture inter-régions suffit pour le RPO/RTO cible avec RDS MySQL.