Une application utilise un cluster de bases de données Amazon Aurora Multi-AZ compatible MySQL avec un réplica en lecture inter-régions pour la reprise après sinistre. L'ingénieur DevOps doit automatiser la promotion du réplica en instance principale si l'instance principale tombe en panne. Quelle solution permettra d'y parvenir ?

La bonne solution utilise AWS Systems Manager Parameter Store pour stocker le point de terminaison, ce qui permet à l'application de le recharger dynamiquement en cas d'échec de connexion. Un événement Amazon EventBridge détecte la défaillance de la base de données et déclenche une fonction AWS Lambda pour promouvoir le réplica et mettre à jour le Parameter Store. Cette approche est robuste car l'application est conçue pour s'adapter aux changements de point de terminaison. Les autres options sont moins efficaces : la première utilise Route 53, qui n'est pas idéal pour la promotion d'un réplica inter-régions et ne gère pas la mise à jour du point de terminaison principal. La deuxième option avec un point de terminaison personnalisé Aurora ne gère pas la promotion automatique du réplica inter-régions. La troisième option modifie le modèle CloudFormation, ce qui est trop lourd et lent pour une reprise après sinistre rapide.