Failover routing for disaster recovery in AWS - Time & Space Complexity
When setting up failover routing for disaster recovery, it is important to understand how the time to switch traffic grows as the system scales.
We want to know how the routing process behaves as more resources or endpoints are involved.
Analyze the time complexity of the following AWS Route 53 failover routing setup.
// Create primary record
aws route53 change-resource-record-sets --hosted-zone-id ZONEID --change-batch '{"Changes":[{"Action":"CREATE","ResourceRecordSet":{"Name":"example.com","Type":"A","SetIdentifier":"Primary","Failover":"PRIMARY","TTL":60,"ResourceRecords":[{"Value":"192.0.2.1"}]}}]}'
// Create secondary record
aws route53 change-resource-record-sets --hosted-zone-id ZONEID --change-batch '{"Changes":[{"Action":"CREATE","ResourceRecordSet":{"Name":"example.com","Type":"A","SetIdentifier":"Secondary","Failover":"SECONDARY","TTL":60,"ResourceRecords":[{"Value":"192.0.2.2"}]}}]}'
// Health check for primary
aws route53 create-health-check --caller-reference "primary-check" --health-check-config '{"IPAddress":"192.0.2.1","Port":80,"Type":"HTTP","ResourcePath":"/health"}'
// Associate health check with primary record
// Route 53 automatically switches to secondary if primary fails
This sequence sets up DNS failover with a primary and secondary endpoint monitored by health checks.
In this setup, the main repeating operations are:
- Primary operation: DNS health checks and routing decisions by Route 53.
- How many times: Health checks run continuously at regular intervals; routing decisions happen each time a health check result is evaluated.
As the number of endpoints or health checks increases, Route 53 must evaluate more health check results to decide routing.
| Input Size (n) | Approx. API Calls/Operations |
|---|---|
| 2 endpoints | 2 health checks evaluated regularly |
| 10 endpoints | 10 health checks evaluated regularly |
| 100 endpoints | 100 health checks evaluated regularly |
Pattern observation: The number of health checks and routing evaluations grows linearly with the number of endpoints.
Time Complexity: O(n)
This means the time to evaluate health and decide routing grows directly in proportion to the number of endpoints monitored.
[X] Wrong: "Failover routing time stays the same no matter how many endpoints we add."
[OK] Correct: Each additional endpoint adds a health check to evaluate, so the system must do more work, increasing the time linearly.
Understanding how failover routing scales helps you design reliable systems that respond quickly during outages, a key skill in cloud infrastructure roles.
"What if we added a global traffic policy with multiple failover groups? How would the time complexity change?"
Practice
Solution
Step 1: Understand failover routing purpose
Failover routing is designed to keep services available by switching traffic to a backup if the main server fails.Step 2: Eliminate unrelated options
Options about speed, cost, or blocking traffic do not describe failover routing's main goal.Final Answer:
To automatically send users to a backup server if the main server fails -> Option DQuick Check:
Failover routing = automatic backup switch [OK]
- Confusing failover with performance improvement
- Thinking failover blocks traffic
- Assuming failover reduces costs
Solution
Step 1: Identify routing policies in Route 53
Route 53 offers several routing policies, including latency, geolocation, weighted, and failover.Step 2: Match failover routing policy to disaster recovery
Failover routing policy is specifically designed to route traffic to a backup when the primary fails.Final Answer:
Failover routing policy -> Option CQuick Check:
Failover routing policy = failover setup [OK]
- Choosing latency or weighted policies for failover
- Confusing geolocation with failover
- Not knowing Route 53 routing policy names
Primary: IP 10.0.0.1 (health check enabled)
Secondary: IP 10.0.0.2 (backup)Solution
Step 1: Understand health check failure effect
If the primary health check fails, Route 53 detects the primary is unhealthy.Step 2: Apply failover routing behavior
Failover routing sends traffic to the secondary (backup) IP when primary is unhealthy.Final Answer:
Traffic switches to secondary IP 10.0.0.2 -> Option AQuick Check:
Primary down = traffic to backup [OK]
- Assuming traffic stays on primary despite failure
- Thinking traffic is blocked during failover
- Believing traffic splits evenly without weighting
Solution
Step 1: Check health check association
Failover routing requires the primary record to have a health check to detect failure.Step 2: Understand impact of missing health check
If the health check is missing or not linked, Route 53 never detects primary failure, so no failover occurs.Final Answer:
Health check is not associated with the primary record -> Option BQuick Check:
Failover needs health check linked to primary [OK]
- Ignoring health check association
- Blaming backup IP without checking health check
- Confusing routing policies
- Misunderstanding TTL effects
Solution
Step 1: Understand failover routing setup
Failover routing requires a primary record with a health check and a secondary record without a health check as backup.Step 2: Evaluate options for disaster recovery
Create two records with failover routing; primary record with health check in us-east-1, secondary record without health check in us-west-2 correctly sets primary with health check and backup without health check, enabling automatic failover.Step 3: Eliminate other options
Weighted routing does not provide automatic failover; geolocation routes by location, not health; latency routing routes by speed, not failure.Final Answer:
Create two records with failover routing; primary record with health check in us-east-1, secondary record without health check in us-west-2 -> Option AQuick Check:
Failover needs primary health check and backup record [OK]
- Using weighted routing instead of failover
- Assigning health check to backup record
- Confusing geolocation with failover
- Expecting latency routing to handle failover
Ready to prove it?
Pass the test and this pattern moves unknown
