Route 53 Routing Policies: Failover, Latency, Geolocation - When to Use What?

Key Takeaway

Failover for disaster recovery (DR), Latency for lowest latency, Geolocation for regional content, Weighted for traffic ratio distribution. Choose Simple for single resource, Latency for performance optimization, Geolocation for regional services, Weighted for test deployments.

What are Route 53 Routing Policies?

Route 53 routing policies determine how to respond to DNS queries. When you have multiple resources for the same domain, they define which resource's IP address to return.

User DNS Query: example.com
         ↓
    Route 53
    (Apply routing policy)
         ↓
    Response: 52.1.2.3 (selected resource IP)

8 Routing Policies at a Glance

Policy	Purpose	Routing Criteria	Health Check
Simple	Single resource	None (single value)	Not supported
Weighted	Traffic ratio distribution	Weight ratio	Supported
Failover	Disaster recovery (DR)	Health check status	Required
Latency	Performance optimization	Network latency	Supported
Geolocation	Regional content	User location (country/continent)	Supported
Geoproximity	Location-based + bias	Resource distance + bias value	Supported
Multivalue Answer	Load distribution	Random (up to 8)	Supported
IP-based	IP range routing	Client IP	Supported

Simple Routing

How It Works

The most basic policy, routing all traffic to a single resource.

Simple Routing:

All DNS queries → Single resource (e.g., 52.1.2.3)

Features

• Can specify one or multiple IP addresses in a single record
• When multiple IPs specified, returns one randomly (client chooses)
• Health check NOT supported

When Suitable

• Only one server/resource exists
• Simple website
• No complex routing logic needed

Weighted Routing

How It Works

Distributes traffic by ratio using weights assigned to multiple resources.

Weighted Routing Example:

Resource A (Weight: 70) → 70% traffic
Resource B (Weight: 20) → 20% traffic
Resource C (Weight: 10) → 10% traffic

Use Cases

1. Canary Deployment

Production v1 (Weight: 90) → 90% traffic
New version v2 (Weight: 10) → 10% traffic (testing)

2. A/B Testing

Version A (Weight: 50) → 50%
Version B (Weight: 50) → 50%

3. Gradual Migration

Old DC  (Weight: 80 → 50 → 20 → 0)
AWS     (Weight: 20 → 50 → 80 → 100)

Weight Values

• Range: 0-255
• Weight 0 = no traffic (disabled)
• All resources at Weight 0 = equal distribution

Failover Routing

How It Works

Active-passive configuration that automatically switches to Secondary when Primary resource fails.

Failover Routing:

                    Health Check
                        ↓
Normal: Query → Primary (active)

Failure: Query → Secondary (passive/standby)

Required Configuration

1. Primary record: Health check connection required
2. Secondary record: Used when Primary fails
3. Health check: Monitors Primary status

Health Check Types

Type	Checks
HTTP/HTTPS	Endpoint response code (2xx, 3xx)
TCP	TCP connection availability
HTTP String Match	Specific string in response body
Calculated Health Check	Combination of other health checks (AND/OR)
CloudWatch Alarm	Based on CloudWatch alarm state

When Suitable

• Disaster recovery (DR) scenarios
• Active-passive architecture
• Automatic failover on primary resource failure

Latency-based Routing

How It Works

Routes to AWS region resource that provides lowest network latency to the user.

Latency-based Routing:

Korean User
    ↓
Route 53 (measure latency)
    ↓
Seoul Region (lowest latency) → Selected
Virginia Region (higher latency)
Frankfurt Region (higher latency)

Features

• AWS collects/manages latency data
• Geographic distance ≠ Latency (varies by network path)
• Need to create records for each region

Latency vs Geolocation

Item	Latency	Geolocation
Routing Criteria	Network latency	Geographic location
Purpose	Performance optimization	Regional content
Result	Fastest region	Specified region

Geolocation Routing

How It Works

Routes to specific resources based on user's geographic location (country/continent).

Geolocation Routing:

Korean User     → Korean language server
US User         → English server
European User   → German/English server
Other (Default) → Global server

Use Cases

• Regional content delivery (language, legal requirements)
• Content restrictions (copyright, regional restrictions)
• Compliance (data residency requirements)

Required Setting: Default Record

⚠️ Important: Default record required!

Needed for users from locations not specified
Without it, "NODATA" response returned for unmatched users

Geolocation vs Latency

Scenario	Recommended Policy
Regional language/content delivery	Geolocation
Data residency compliance	Geolocation
Best performance delivery	Latency
User experience optimization	Latency

Geoproximity Routing

How It Works

Routes based on resource's physical location with bias values to adjust traffic distribution.

Geoproximity + Bias:

Seoul Region (Bias: +50)  → Receives traffic from wider area
Tokyo Region (Bias: 0)    → Default range
Singapore Region (Bias: -25) → Narrower range

Bias Values

• Positive (+): Attract more traffic to that resource
• Negative (-): Reduce traffic to that resource
• Range: -99 to +99

When Suitable

• Concentrate traffic to specific region
• Balance traffic between regions
• Including non-AWS resources

Requirement

Route 53 Traffic Flow required (visual policy editor)

Multivalue Answer Routing

How It Works

Returns up to 8 healthy records randomly to DNS queries. Client-side load balancing effect.

Multivalue Answer:

DNS Query Response:
- 52.1.1.1 (healthy)
- 52.2.2.2 (healthy)
- 52.3.3.3 (healthy)
- 52.4.4.4 (unhealthy → excluded)

Simple vs Multivalue Answer

Item	Simple	Multivalue Answer
Health Check	Not supported	Supported
Response Records	All values	Healthy only (up to 8)
Availability	Lower	Higher

When Suitable

• Simple load balancing needed
• Distribute across resources without ELB
• Return only healthy resources via health check

IP-based Routing

How It Works

Routes to specific resources based on client IP address range (CIDR).

IP-based Routing:

CIDR: 203.0.113.0/24 → Server A
CIDR: 198.51.100.0/24 → Server B
Other IPs → Default server

Use Cases

• ISP/network-specific optimized endpoints
• Dedicated servers for specific clients
• Internal network traffic separation

Routing Policy Selection Guide

Decision Tree

What routing do you need?

├─ Only single resource exists → Simple
│
├─ Need failover → Failover + Health Check
│
├─ Need performance optimization → Latency-based
│
├─ Regional content delivery → Geolocation
│
├─ Need traffic ratio distribution
│   ├─ A/B test, canary deployment → Weighted
│   └─ Location-based ratio adjustment → Geoproximity
│
├─ Simple load balancing → Multivalue Answer
│
└─ Routing by specific IP ranges → IP-based

Scenario-Based Selection

Scenario	Recommended Policy
DR (disaster recovery) setup	Failover
Global user performance optimization	Latency
Regional language/content	Geolocation
New version canary testing	Weighted
Simple multi-resource distribution	Multivalue Answer
Dedicated server for specific client	IP-based

Health Check Details

Health Check Configuration

Health Check Parameters:

- Protocol: HTTP, HTTPS, TCP
- Endpoint: IP or domain
- Port: 80, 443, or custom
- Path: /health, /status, etc.
- Interval: 10 or 30 seconds
- Failure Threshold: 1-10 times
- String Match: Check in response body

Calculated Health Check

Combine multiple health checks with AND/OR conditions:

Example: Pass if 2 or more of 3 are healthy

Health Check A: Healthy ✓
Health Check B: Healthy ✓
Health Check C: Unhealthy ✗

Result: Pass (2/3 healthy)

SAA-C03 Exam Focus Points

1. ✅ Failover: DR scenario = Failover + Health Check
2. ✅ Latency vs Geolocation: Performance = Latency, Regional content = Geolocation
3. ✅ Weighted: Canary deployment, A/B testing, gradual migration
4. ✅ Simple: No health check support (not for high availability)
5. ✅ Geolocation Default: Required setting (NODATA without it)
6. ✅ Health Check: Required for Failover, optional for others

Frequently Asked Questions

Q: Should I use Latency or Geolocation?

Depends on the purpose. Use Latency for fastest response to users, Geolocation to serve specific content to specific regions. Geographically close doesn't always mean faster.

Q: Why is a Default record needed in Geolocation?

To handle unmatched locations. If IP location can't be determined or user is from an unconfigured region, NODATA response is returned. Prevent this with a Default record.

Q: How to completely disable one resource in Weighted Routing?

Set Weight to 0. No traffic goes to resources with Weight 0. Useful for maintenance or issues.

Q: What's the difference between Multivalue Answer and ELB?

Multivalue Answer is DNS-level distribution, ELB is actual load balancing. Multivalue Answer is suitable for simple distribution, but use ELB if you need session persistence, fine-tuned health checks, etc.

Q: What happens when a health check fails?

Depends on the policy:

• Failover: Automatically switches to Secondary
• Weighted/Latency/Multivalue: Excludes that record from responses
• Simple: No health check support, always responds

Q: Can I combine multiple routing policies?

Possible with Alias records and record chaining. Example: Select region with Latency policy → Distribute versions within region with Weighted.

---

Related Posts

• ELB Types Comparison (ALB, NLB, GLB, CLB)
• CloudFront Distribution Optimization
• Multi-AZ vs Multi-Region Strategy

---

References

• AWS Route 53 Routing Policies Official Documentation
• Route 53 Health Checks Official Documentation
• Route 53 Pricing