A company has an application that is using a MySQL-compatible Amazon Aurora Multi-AZ DB cluster as the database. A cross-Region read replica has been created for disaster recovery purposes. A DevOps engineer wants to automate the promotion of the replica so it becomes the primary database instance in the event of a failure.
Which solution will accomplish this?
To promote a read replica to a primary instance automatically in case of a failure, using Amazon EventBridge to detect database failure and trigger an AWS Lambda function is the preferred approach. The Lambda function can promote the replica and update the endpoint stored in AWS Systems Manager Parameter Store. The application should then be coded to reload this endpoint if the connection fails, ensuring it points to the new primary instance without manual intervention. This solution leverages AWS services effectively to automate the entire process.
doesnt failover happen automatically in aurora?
Aurora supports automated failover for a single cluster. [Be it a global Aurora cluster or a multi AZ/region deployment] In this case it's implied that the read-replica is not part of the cluster. that's my best guess.
D is the correct answer. Explanation: To automate the promotion of a read replica to the primary instance in the event of a failure, we need to detect the failure and then invoke an AWS Lambda function to promote the replica instance. This can be achieved using Amazon EventBridge. Option A is incorrect because using a CNAME with health checks doesn't provide an automated way to promote the read replica. Additionally, subscribing an Amazon SNS topic to Amazon RDS failure notifications from AWS CloudTrail doesn't help to promote the replica. Option B is incorrect because a custom endpoint is not required to promote the read replica. Additionally, using AWS CloudTrail to run an AWS Lambda function to promote the replica instance doesn't provide an automated way to update the application endpoint to point to the newly promoted instance.
Option D is the correct solution Option C is incorrect because modifying the AWS CloudFormation template requires manual intervention and cannot be automated. Additionally, creating an Amazon CloudWatch alarm to invoke the Lambda function after the failure event occurs doesn't provide an automated way to promote the replica instance. Therefore, Option D is the correct solution.
D make most sense.
D is the answer
D: Refference:https://aws.amazon.com/es/blogs/database/cross-region-cross-account-disaster-recovery-using-amazon-aurora-global-database/
D it is
Correct answer is B Here is why. Previously, you might have used the CNAMES mechanism to set up Domain Name Service (DNS) aliases from your own domain to achieve similar results. By using custom endpoints, you can avoid updating CNAME records when your cluster grows or shrinks. Custom endpoints also mean that you can use encrypted Transport Layer Security/Secure Sockets Layer (TLS/SSL) connections. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html#Aurora.Endpoints.Custom
A is correct: Using Amazon Route 53 CNAME with health checks is the way for failover recommended by AWS: https://aws.amazon.com/blogs/database/cross-region-disaster-recovery-using-amazon-aurora-global-database-for-amazon-aurora-postgresql/
option D is not either providing seemless solution, in option D application needed to be reload and that will cause downtime.