Which solution will accomplish this?
Configure a latency-based Amazon Route 53 CNAME with health checks so it points to both the primary and replica endpoints. Subscribe an Amazon SNS topic to Amazon RDS failure notifications from AWS CloudTrail and use that topic to trigger an AWS Lambda function that will promote the replica instance as the master.
Create an Aurora custom endpoint to point to the primary database instance. Configure the application to use this endpoint. Configure AWS CloudTrail to run an AWS Lambda function to promote the replica instance and modify the custom endpoint to point to the newly promoted instance.
Create an AWS Lambda function to modify the application’s AWS Cloud Formation template to promote the replica, apply the template to update the stack, and point the application to the newly promoted instance. Create an Amazon CloudWatch alarm to trigger this Lambda function after the failure event occurs.
Store the Aurora endpoint in AWS Systems Manager Parameter Store. Create an Amazon EventBridge (Amazon CloudWatch Events) event that defects the database failure and runs an AWS Lambda function to promote the replica instance and update the endpoint URL stored in AWS Systems Manager Parameter Store. Code the application to reload the endpoint from Parameter Store if a database connection fails.
Explanations:
While using Route 53 with health checks is a valid approach, it does not directly promote the replica instance. The solution lacks a mechanism to automatically trigger the promotion of the replica instance based on failure notifications. CloudTrail notifications for RDS failures cannot directly trigger a Lambda function without additional configurations.
Although creating a custom endpoint for the primary instance and modifying it to point to the replica is a step in the right direction, this option does not specify how the promotion of the replica will be automatically triggered. It relies on CloudTrail, which is not designed to directly invoke actions like instance promotion.
This option involves modifying the CloudFormation template to promote the replica, but CloudFormation is not the right tool for immediate operational responses like failover. The process would also be too slow and complex for a real-time disaster recovery scenario since CloudFormation updates can take time and may not react quickly enough to database failures.
This solution effectively combines using AWS Systems Manager Parameter Store for endpoint management with an event-driven architecture using Amazon EventBridge to detect failures and trigger a Lambda function. The Lambda function can promote the read replica and update the endpoint, allowing the application to automatically retrieve the new database endpoint and establish a connection seamlessly. This ensures a rapid response to database failures.
I rank that the answer is:
Store the Aurora endpoint in AWS Systems Manager Parameter Store. Create an Amazon EventBridge (Amazon CloudWatch Events) event that defects the database failure and runs an AWS Lambda function to promote the replica instance and update the endpoint URL stored in AWS Systems Manager Parameter Store. Code the application to reload the endpoint from Parameter Store if a database connection fails.