Question

Difficulty: MediumEnhancing Reliability and Disaster Recovery

An enterprise operates a multi-region web application across us-east-1 (active) and us-west-2 (passive). The application tier consists of Amazon EC2 instances in an Auto Scaling group behind an Application Load Balancer (ALB). The database tier uses an Amazon Aurora Global Database with the primary cluster in us-east-1. Traffic is routed using an Amazon Route 53 failover routing policy pointing to the primary ALB with an associated health check. During a simulated database outage in us-east-1, the application became unavailable, but Route 53 did not fail over to us-west-2 because the Route 53 health check, which points to a static HTML page on the EC2 instances, remained healthy.

Which action should a solutions architect take to resolve this issue and enhance the disaster recovery reliability?

  1. Update the Route 53 health check to query a dynamic health check endpoint on the application servers that verifies connectivity to the primary database cluster, returning a failure response if the database is unreachable.Answer
  2. B
    Modify the Route 53 primary alias record pointing to the Application Load Balancer to enable the 'Evaluate Target Health' option, and remove the external health check configuration.
  3. C
    Configure a CloudWatch metric alarm for Amazon Aurora replication lag in the secondary region, and configure the Route 53 health check to fail when the replication lag exceeds the disaster recovery threshold.
  4. D
    Create a duplicate Route 53 private hosted zone in the secondary region and associate it with the primary VPC to override external routing tables during database outages.

Answer

Update the Route 53 health check to query a dynamic health check endpoint on the application servers that verifies connectivity to the primary database cluster, returning a failure response if the database is unreachable.
The correct answer is to configure the health check to query a dynamic health endpoint on the EC2 instances that performs a database query, and fails if the database is unreachable. Route 53 DNS failover relies on health checks to determine the status of the endpoints. A static health check page only confirms that the web server is running. To detect a database outage, the health check must monitor an endpoint that actively validates connectivity to the database, causing Route 53 to fail over to the secondary region when the database becomes unavailable.

Step-by-Step Solution

1
Analyze why the DNS failover failed during the simulated database outage.
The Route 53 health check was checking a static HTML page, which only verified that the web servers (EC2 instances) were running. It did not verify whether the application could connect to the database.
This explains the failure of the automated failover mechanism.
2
Design an application-aware health check endpoint.
Create a dynamic endpoint (such as /health/status) on the application servers that performs a simple test query against the Aurora database.
This ensures the health check evaluates the full application stack, including critical backend dependencies.
3
Update the Route 53 health check configuration.
Point the Route 53 health check to the newly created dynamic endpoint so that database connectivity issues will result in a health check failure, initiating failover to the standby region.
This aligns the DNS routing decisions with the actual functional status of the application stack.

Key Concept

To ensure reliable disaster recovery failover in a multi-region architecture, Route 53 health checks must monitor dynamic application endpoints that validate backend dependencies (such as database connectivity) rather than simple web server availability or static files.
Rate this question