Examkin

Question

Difficulty: Very hardRoute 53 Routing Policies and DNS Failover Strategies

An enterprise is designing a disaster recovery (DR) architecture for a critical web application. The primary infrastructure is located in the us-east-1 Region, consisting of an Application Load Balancer (ALB) and an Amazon Aurora PostgreSQL Global Database. The passive DR site is in the eu-west-1 Region, using a Pilot Light strategy where application servers are scaled to zero to minimize costs, and an Aurora read replica is maintained for data replication.

The Solutions Architect must configure Amazon Route 53 to implement automatic failover. Under normal operations, all client traffic must be routed to us-east-1. If the primary region's compute resources or database fail, Route 53 must redirect all traffic to eu-west-1. The architect must ensure that traffic is not routed to eu-west-1 before the pilot light resources are scaled up, and Route 53 does not route traffic to both regions simultaneously.

Which TWO configurations should the Solutions Architect implement to meet these requirements?

  1. Configure a Route 53 primary failover record pointing to the us-east-1 ALB with Evaluate Target Health set to Yes. Configure a secondary failover record pointing to the eu-west-1 ALB with Evaluate Target Health set to No.Answer
  2. Create a Route 53 metric-based health check linked to a CloudWatch alarm that monitors Aurora database health and database connection failures in us-east-1, and associate this health check with the primary Route 53 record.Answer
  3. C
    Configure Route 53 Latency routing records for both us-east-1 and eu-west-1, associating each record with a standard Route 53 HTTP health check to ensure failover to the healthy region.
  4. D
    Set the Route 53 Failover routing policy directly on the Amazon Aurora database cluster endpoints to automate the promotion of the Aurora read replica in eu-west-1 during a failover.
  5. E
    Configure both primary and secondary Route 53 failover records with Evaluate Target Health set to Yes, relying on the eu-west-1 ALB target group health checks to trigger EC2 Auto Scaling policies when DNS queries begin failing over.

Answer

Configure the primary failover record pointing to the primary ALB with Evaluate Target Health set to Yes while setting Evaluate Target Health to No on the secondary failover record, and create a Route 53 metric-based health check linked to a CloudWatch alarm monitoring database health.
The correct configurations ensure robust active-passive DNS failover. First, the primary failover record must point to the primary ALB with target health evaluation enabled, while the secondary failover record pointing to the standby ALB must have target health evaluation disabled (set to No). This is because the standby region uses a Pilot Light DR pattern where application servers are scaled to zero. A target-health-check enabled secondary record would be seen as unhealthy by Route 53 due to zero healthy registered targets, causing Route 53 to route to both endpoints if the primary fails. Second, Route 53 health checks can be linked to CloudWatch alarms. Because standard ALB health checks do not monitor database status, creating a metric-based health check linked to a CloudWatch alarm that tracks database connectivity and write availability ensures Route 53 will fail over if the primary database cluster becomes unavailable.

Step-by-Step Solution

1
Determine the correct Route 53 routing policy for an active-passive disaster recovery configuration.
Identify that a Failover routing policy must be used to ensure all traffic goes to the primary region (us-east-1) under normal conditions, and is redirected to the secondary region (eu-west-1) only during an outage.
Active-passive failover requires directing all traffic to the active site, unlike active-active policies such as Latency routing.
2
Analyze target health evaluation settings for both the primary and secondary ALB endpoints when using a Pilot Light strategy.
Primary failover record points to the primary ALB with Evaluate Target Health set to Yes. Secondary failover record points to the secondary ALB with Evaluate Target Health set to No.
Because the secondary region runs in a Pilot Light state with compute instances scaled to zero, the secondary ALB has no healthy targets and would fail health checks. Setting Evaluate Target Health to Yes on the secondary would cause Route 53 to see both regions as unhealthy and route traffic to both. Setting it to No ensures Route 53 always treats the secondary as healthy when the primary fails.
3
Integrate database health checks into Route 53 routing decisions.
Configure a CloudWatch alarm monitoring Aurora database health metrics (such as connection count or write availability) and link a Route 53 metric-based health check to this alarm, associating it with the primary failover record.
Standard Route 53 health checks and ALB target group health checks only evaluate compute target health, not database availability. A metric-based health check ensures Route 53 triggers a failover if the database layer fails while the web servers remain running.

Key Concept

Configuring Route 53 active-passive DNS failover in a Pilot Light DR scenario requires coordinating compute scaling states with Route 53's health evaluation mechanisms (Evaluate Target Health) and using CloudWatch alarm-based health checks to incorporate backend database health into the DNS failover decision.
Rate this question

Topics

Route 53 Routing Policies and DNS Failover Strategies

More questions from this topic