Question

Difficulty: MediumEnhancing Reliability and Disaster Recovery

An enterprise operates a public-facing web application deployed across two AWS Regions: us-east-1 (primary) and us-west-2 (standby) for disaster recovery. The architecture consists of an Application Load Balancer (ALB) and an Auto Scaling group of EC2 instances in each region. The company uses Amazon Route 53 with failover routing policies. The primary alias record has 'Evaluate Target Health' set to 'No' and is associated with a Route 53 HTTP health check that directly queries the ALB DNS name. During a recent database outage in the primary region, the web servers behind the primary ALB began returning HTTP 500 errors to users, but DNS failover to the standby region did not occur. Which action should the solutions architect take to ensure reliable failover to the standby region during future application or database outages?

  1. A
    Create a Route 53 Private Hosted Zone for the application domain, associate it with the VPCs in both regions, and use simple routing policies to map the domain to interface VPC endpoints for the Application Load Balancers.
  2. B
    Modify the disaster recovery strategy to a Pilot Light pattern, terminate the standby EC2 instances, and replace the Route 53 failover records with latency-based routing records that lack health checks.
  3. Change the Route 53 primary alias record configuration to set 'Evaluate Target Health' to 'Yes' and configure the ALB target group health check to query a specific path that validates database connectivity.Answer
  4. D
    Deploy a single NAT Gateway in the primary region's public subnets to consolidate all outbound application server traffic and configure the ALB target group health checks to route through this NAT Gateway.

Answer

The correct answer is the option that proposes changing the Route 53 primary alias record configuration to set 'Evaluate Target Health' to 'Yes' and configuring the ALB target group health check to query a specific path that validates database connectivity.
Setting 'Evaluate Target Health' to 'Yes' on the primary Route 53 alias record forces Route 53 to determine health based on the registered targets of the ALB rather than the availability of the ALB endpoint itself. Since the application servers were returning 500 errors during a database outage, updating the target group's health checks to test a path verifying database connectivity ensures the instances are marked unhealthy, triggering Route 53 to fail over to the standby region.

Step-by-Step Solution

1
Identify why Route 53 did not fail over during the database outage.
The primary alias record has 'Evaluate Target Health' set to 'No', and the health check only monitors the ALB endpoint itself, which remains responsive even if the backend instances or databases are failing.
Understanding the root cause is necessary to configure correct health check inheritance.
2
Configure Route 53 to inherit the health status of the ALB's backend targets.
Enable 'Evaluate Target Health' on the Route 53 primary alias record.
This instructs Route 53 to evaluate the health of the targets registered with the ALB's target groups, rather than just the load balancer itself.
3
Align the ALB target group health check with application dependency health.
Configure the target group health check to query a path that verifies active database connectivity.
This ensures that if the database fails, the target group marks the instances as unhealthy, which bubble up to Route 53 to trigger failover.

Key Concept

Disaster recovery failover routing with health check propagation and target evaluation
Rate this question