Une application SaaS s'exécute sur API Gateway (HTTPS), AWS Lambda et Aurora Serverless v1 déployés sur plusieurs AZ. Le déploiement a utilisé AWS SAM. Il n'y a pas de plan de reprise après sinistre (DR). L'entreprise exige que l'application puisse être récupérée dans une autre région AWS avec un RTO de 5 minutes et un RPO de 1 minute. Quelle approche de reprise après sinistre répond à ces objectifs de récupération ?

La bonne approche est de convertir la base de données Aurora Serverless v1 en une base de données globale Aurora MySQL standard couvrant les régions source et cible, puis de lancer l'application dans la région cible et de configurer les deux déploiements régionaux en actif-passif. Aurora Global Database offre un RPO de 1 seconde et un RTO de moins d'1 minute, ce qui dépasse les exigences de 1 minute et 5 minutes respectivement. Le déploiement de l'application dans la région cible et la configuration actif-passif garantissent que l'application est prête à prendre le relais rapidement. Créer un réplica en lecture d'Aurora Serverless v1 ne permet pas un RPO de 1 minute car Aurora Serverless v1 ne supporte pas les réplicas inter-régions. Créer un cluster avec plusieurs instances d'écriture n'est pas une fonctionnalité d'Aurora Serverless v1 et ne répond pas aux exigences de DR inter-régions. L'option de convertir en base de données globale Aurora MySQL standard avec un runbook pour le déploiement de l'application est moins efficace que d'avoir l'application déjà déployée et configurée en actif-passif, ce qui est essentiel pour un RTO de 5 minutes.