Failover and Geolocation Routing

Failover routing implements an active-passive configuration: one record is designated Primary and another is Secondary. Route 53 always returns the Primary record as long as its health check passes. If the Primary becomes unhealthy, Route 53 automatically switches to returning the Secondary record.

Failover routing is the go-to pattern for disaster recovery scenarios where you have a production environment (primary) and a standby environment (secondary) that should only receive traffic when the primary is down.

To set up failover routing, create two records with the same DNS name: one with Failover=PRIMARY and one with Failover=SECONDARY. Attach a health check to the Primary record. The Secondary record should also have a health check if it points to a resource that could fail independently.

The Secondary record acts as a static fallback—it can point to an S3 static website, a maintenance page, or a scaled-down standby environment. Even if the Secondary has no health check, Route 53 always falls back to it when the Primary fails.

Failover routing creates an active-passive setup: only the Primary serves traffic during normal operation; the Secondary sits idle waiting to take over. This minimises cost for the standby but results in slightly longer recovery time (the time for DNS TTL to expire and Route 53 to switch).

For active-active setups (both resources serving traffic simultaneously), use Weighted routing (equal weights) or Latency routing. If one resource fails, its health check fails and Route 53 removes it from DNS responses automatically—achieving active-active with built-in failover.

Geolocation routing routes DNS queries based on the geographic location of the DNS resolver (typically the user's ISP resolver or AWS Route 53 Resolver). You create records for specific continents, countries, or US states, and Route 53 returns the record whose location most specifically matches the query source.

If no specific location record matches, Route 53 returns a default record (if configured). Without a default, queries from unmatched locations receive NODATA. Always create a default record to handle users from locations you have not explicitly configured.

Key use cases for Geolocation routing:

• Language-specific content: route French speakers to a French-language CDN origin, German speakers to a German origin
• Regulatory compliance: ensure EU user data stays in EU Regions (GDPR), or block access from specific countries
• Localised pricing or availability: show region-specific prices or restrict services to supported territories
• Geo-blocking: return a block page or empty response for users from restricted locations by pointing their geolocation record to a maintenance endpoint

Route 53 matches the most specific geolocation: a state-level record takes precedence over a country-level record, which takes precedence over a continent-level record, which takes precedence over the default. US state-level geolocation is only available for the United States.

If you omit a default record and a user's location matches no configured record, Route 53 returns NXDOMAIN or NODATA—this silently breaks access for users in unconfigured regions. Always add a default geolocation record as a catch-all to avoid silent failures.

Geoproximity routing routes traffic based on the physical geographic distance between users and resources, with an optional bias to expand or shrink the effective routing radius of each resource. A positive bias expands the geographic area that a resource serves; a negative bias shrinks it.

Geoproximity is only available through Traffic Flow (Route 53's visual routing policy editor) and supports both AWS Regions (which Route 53 knows the coordinates of automatically) and custom resource locations where you provide latitude and longitude.

Route 53 Traffic Flow is a visual policy editor that lets you build complex routing logic by combining multiple routing policies in a tree-like diagram. For example, you can first apply geolocation to separate EU traffic, then apply latency within EU to choose the best-performing Region, and finally use weighted routing within each Region for blue-green deployments.

Traffic Flow policies are versioned, allowing you to test changes safely. You associate a Traffic Flow policy with one or more DNS names, and updates to the policy propagate instantly without recreating individual records.

Failover routing can be nested inside other policies. A common pattern: use Latency routing to pick the closest Region, but within each Region use a Failover record so if the primary endpoint in that Region fails, traffic automatically shifts to a secondary endpoint in the same Region.

Another pattern: multi-Region active-passive using Latency routing for the primary endpoint. If the primary Region's health check fails, Route 53 falls through to the next-lowest-latency healthy Region—effectively combining latency optimisation with DR failover.

For failover routing to work correctly, the Primary record must** have a health check attached. Without a health check, Route 53 treats the Primary as always healthy and never switches to the Secondary. The Secondary record may optionally have its own health check; if the Secondary also fails, Route 53 returns the Secondary's address anyway (it is the last resort).

Health check types you can use with failover: HTTP/HTTPS endpoint checks, TCP checks, and CloudWatch alarm checks (useful for composite application health signals that combine multiple metrics).

This distinction appears frequently on the SAA-C03 exam:

• Geolocation: routes by where the user is located geographically—always returns the same endpoint for a given country/continent regardless of performance; used for content localisation and compliance
• Latency: routes by network performance to the user—may route a user in Europe to us-east-1 if it is faster than eu-west-1 at that moment; used for performance optimisation

Keywords in exam questions: 'comply with data residency', 'country-specific content', 'block users from certain regions' → Geolocation. 'closest Region', 'lowest latency', 'best performance for global users' → Latency.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Failover routing creates active-passive HA by switching to the Secondary when the Primary's health check fails, Geolocation routing directs users by geographic origin for compliance and localisation, and Geoproximity routing uses physical distance with configurable bias via Traffic Flow. Always add a default geolocation record to handle unmatched locations. Next up we explore health checks and DNS failover in depth.