Une application web s'exécute sur des instances EC2 derrière un ALB dans un groupe Auto Scaling réparti sur plusieurs AZ et utilise une instance Amazon RDS for MySQL. Route 53 pointe vers l'ALB avec un enregistrement d'alias. La politique de l'entreprise exige désormais un site de reprise après sinistre (DR) géographiquement isolé avec un RTO de 4 heures et un RPO de 15 minutes, avec un minimum de modifications de la pile d'applications. Quelle approche de DR satisfait ces exigences avec le moins de modifications d'application ?

L'option correcte répond aux exigences de RTO et RPO en utilisant une approche de reprise après sinistre multi-régions avec un réplica en lecture RDS. La création d'un environnement dupliqué dans une autre région assure une isolation géographique. L'utilisation d'un réplica en lecture RDS dans la région de DR, combinée à sa promotion en cas de sinistre, permet d'atteindre un RPO de 15 minutes et un RTO de 4 heures. Route 53 avec une politique de basculement basée sur la vérification de l'état de santé automatise la redirection du trafic. Les autres options sont moins optimales : La création d'un environnement dans une autre zone de disponibilité ne fournit pas une isolation géographique suffisante pour un DR robuste. Le routage basé sur la latence de Route 53 n'est pas une stratégie de basculement pour le DR. La copie et la restauration de snapshots RDS en cas de sinistre augmenteraient considérablement le RTO et le RPO, ne respectant pas les exigences.