Une entreprise doit implémenter une solution de reprise après sinistre pour une application critique qui s'exécute actuellement dans une seule région AWS. Le frontend web utilise des instances EC2 derrière un Application Load Balancer (ALB). L'application écrit dans une instance de base de données Amazon RDS for MySQL et génère des documents traités dans un compartiment Amazon S3. L'équipe financière exécute des requêtes directes sur la base de données pour produire des rapports ; pendant les périodes de pointe, ces requêtes consomment des ressources de la base de données et dégradent les performances de l'application. Concevez une solution de reprise après sinistre qui minimise la perte de données et élimine l'impact sur les performances des requêtes de l'équipe financière. Quelle solution répond à ces exigences ?

La bonne solution propose une stratégie de reprise après sinistre multi-régions avec un objectif de point de récupération (RPO) et un objectif de temps de récupération (RTO) faibles. La création d'un réplica en lecture RDS dans une autre région permet de minimiser la perte de données et d'isoler les requêtes de l'équipe financière, améliorant ainsi les performances de l'application. La copie des AMI et la réplication S3 inter-régions préparent l'infrastructure pour un déploiement rapide en cas de sinistre. L'option 1 est incorrecte car la migration vers DynamoDB est un changement architectural majeur qui n'est pas demandé et les tables globales DynamoDB ne sont pas une solution directe pour une base de données relationnelle existante. L'option 2 est incorrecte car elle implique de lancer des instances EC2 supplémentaires en permanence dans la région de reprise, ce qui augmente les coûts sans être strictement nécessaire pour un scénario de reprise après sinistre "pilote light" ou "warm standby". L'option 4 est incorrecte car la restauration d'une base de données à partir d'instantanés horaires peut entraîner une perte de données plus importante (RPO élevé) par rapport à un réplica en lecture. L'ajout d'ElastiCache n'est pas directement lié à la stratégie de reprise après sinistre et n'élimine pas l'impact des requêtes financières sur la base de données principale.