AWS Route 53 Global Load Balancing: Latency, Failover & Routing Policies

Simple explanation for beginners

Here is what happens when a user visits a multi-region app built with Route 53:

1. The user’s browser asks DNS: “What is the IP address for app.example.com?”
2. That query reaches Route 53, which applies your routing policy (latency, geolocation, weighted, failover, etc.).
3. Route 53 returns a regional record, for example the DNS name of an ALB in us-east-1 or ap-northeast-1.
4. The user’s browser connects directly to that regional endpoint.
5. The DNS answer is cached for the TTL duration. Until that cache expires, the user stays routed to the same regional endpoint.

If you are new to Route 53 itself, covering hosted zones, record types, and how DNS resolution works, start with DNS with Route 53 before diving into routing policies. For the initial setup walkthrough, see Route 53 setup. If your app uses internal DNS for private resources, see private hosted zones.

When to use Route 53 global routing

• Active-active multi-region apps: Run your full application stack in multiple AWS regions simultaneously and route each user to the nearest or fastest region.
• Disaster recovery with automatic failover: Keep a secondary region on standby and have Route 53 automatically switch traffic when your primary region fails health checks.
• Blue-green and canary deployments: Gradually shift traffic from an old environment to a new one using weighted routing. See blue-green deployments and canary deployments for how this works in practice.
• Compliance and localization: Route European users to EU infrastructure for GDPR data-residency, or serve different content by country.
• Globally distributed users needing low latency: Send each user to the AWS region with the lowest measured network latency for their location.

When not to use Route 53 for this

Route 53 is the wrong tool when you need:

• Path-based or header-based routing: Route 53 only sees DNS queries, not HTTP requests. Use an ALB for routing based on URL paths, host names, or HTTP headers.
• Per-request load balancing: Route 53 operates at DNS query time, not per-connection. Use an ALB or NLB for that.
• Instant connection-level failover: DNS TTL means failover takes seconds to minutes. AWS Global Accelerator uses Anycast IPs and routes over the AWS backbone with faster failover and no DNS TTL dependency.
• CDN caching or edge acceleration: Use CloudFront for content caching and edge delivery. CloudFront integrates with Route 53 as a DNS alias target, but the CDN features are entirely separate.
• Static global IP addresses: If your application needs a fixed IP that works globally without DNS TTL delays, use AWS Global Accelerator, which provides static Anycast IPs.

How Route 53 global routing works

1. User queries DNS. A user’s device asks their DNS resolver for app.example.com.
2. Query reaches Route 53. The resolver forwards the query to Route 53, the authoritative DNS for your domain.
3. Route 53 evaluates routing policy. Based on your configuration, Route 53 applies latency, geolocation, weighted, or failover logic to select a record.
4. Route 53 checks endpoint health. If EvaluateTargetHealth is enabled, Route 53 skips records pointing to unhealthy endpoints before responding.
5. Route 53 returns a regional record. Route 53 returns the DNS name or IP of the selected regional endpoint, usually an ALB alias.
6. Client caches the answer. The DNS answer is cached for the TTL duration. The user’s browser will not re-query DNS until the cache expires.
7. Client connects to the regional endpoint. The user’s connection goes directly to the selected region. Route 53 is no longer involved.
8. Failover is TTL-bound. If the selected region goes down, users with cached DNS responses will not see the failover until their TTL runs out.

Route 53 routing policies that matter for global traffic steering

Latency-based routing

Sends each user to the AWS region with the lowest network latency for their location. Route 53 maintains latency measurements between AWS regions and client IP ranges and uses these to pick the fastest region for each DNS query.

Best for: Active-active multi-region apps where every region runs the full application and you want each user to get the fastest experience automatically.

Watch out for: Latency routing is based on AWS’s historical network measurements, not a live measurement of your specific application’s response time. A region with low network latency but a slow app tier can still win the routing decision.

Example: two latency records for two regions. Route 53 returns the lower-latency one for each user.

{
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "A",
        "SetIdentifier": "us-east-1",
        "Region": "us-east-1",
        "AliasTarget": {
          "HostedZoneId": "Z35SXDOTRQ7X7K",
          "DNSName": "alb-us-east-1.us-east-1.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "A",
        "SetIdentifier": "ap-northeast-1",
        "Region": "ap-northeast-1",
        "AliasTarget": {
          "HostedZoneId": "Z14GRHDCWA56QT",
          "DNSName": "alb-ap-northeast-1.ap-northeast-1.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    }
  ]
}

Geolocation routing

Routes traffic to different endpoints based on the geographic origin of the DNS query, by continent, country, or US state. Unlike latency routing (which optimizes for speed), geolocation routing optimizes for compliance, content localization, or regulatory requirements.

Best for: GDPR data-residency requirements, country-specific content or pricing, or legal obligations to serve users from infrastructure in a specific jurisdiction.

Weighted routing

Splits DNS traffic between multiple endpoints using numeric weights. Records with weights 80 and 20 will receive roughly 80% and 20% of queries respectively. This is the standard approach for implementing DNS-level traffic shifting during blue-green deployments or canary rollouts.

Best for: Gradually shifting traffic from an old deployment to a new one. Start at 5% to the new version, monitor error rates and latency, then ramp to 20%, 50%, 100%.

Failover routing

Creates an active-passive setup across two regions. One record is designated primary; another is secondary. Route 53 monitors the primary using health checks. When health checks fail, Route 53 automatically returns the secondary record to new DNS queries, with no manual intervention required.

Best for: Disaster recovery scenarios where you want automatic regional failover. The secondary can be a full active standby or a minimal fallback. See disaster recovery strategies for how to design the secondary region and choose the right DR pattern.

# Create a primary failover record pointing to the us-east-1 ALB
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABCDE \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "primary",
        "Failover": "PRIMARY",
        "HealthCheckId": "abc12345-1234-1234-1234-abc123456789",
        "AliasTarget": {
          "HostedZoneId": "Z35SXDOTRQ7X7K",
          "DNSName": "alb.us-east-1.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    }]
  }'

Other Route 53 routing policies to know about

These policies exist but are less central to global traffic steering for most applications.

• Geoproximity routing: Routes based on geographic distance to your endpoints, with an optional bias you can adjust to expand or shrink the geographic region each endpoint serves. Requires Route 53 Traffic Flow.
• IP-based routing: Routes traffic based on the CIDR block of the originating IP address. Useful when you know the IP ranges of specific clients or ISPs and want to route them explicitly.
• Multivalue answer routing: Returns multiple healthy records in response to a DNS query (up to 8). Clients pick one at random. It is not a replacement for a load balancer, but provides basic DNS-level redundancy for simple use cases.

Route 53 vs ALB vs AWS Global Accelerator

These three services are commonly confused. They solve different problems at different layers.

In practice, these are often used together: Route 53 routes users to the nearest region, an ALB in that region handles path-based routing and forwards to backend services. Global Accelerator can replace Route 53 in this chain when you need faster failover or consistent performance regardless of DNS caching behavior.

Common architecture patterns

Active-active multi-region with latency routing

Deploy your full application stack in two or more AWS regions, for example us-east-1 and ap-northeast-1. Create latency-based Route 53 records pointing to the ALB in each region. Route 53 automatically sends each user to the region with the lowest latency for their location. Both regions handle live traffic simultaneously, with no idle standby. See multi-region architectures for a full breakdown of this pattern, including data replication and consistency considerations.

Active-passive disaster recovery with failover routing

Run your application in a primary region (e.g., us-east-1) and maintain a standby deployment in a secondary region (e.g., us-west-2). Configure Route 53 failover routing with health checks on the primary record. Under normal conditions, all traffic goes to the primary. If health checks fail, Route 53 automatically switches DNS to the secondary. This pattern maps directly to the Warm Standby and Pilot Light patterns in disaster recovery strategies. For guidance on overall availability design, see designing highly available systems.

Blue-green rollout with weighted routing

Keep your current production environment (“blue”) running and deploy the new version (“green”) in parallel. Create two Route 53 weighted records for the same domain, initially weight 100 on blue and 0 on green. Gradually shift traffic: 5% to green, watch error rates, then 20%, 50%, 100%. Once stable, decommission blue. See blue-green deployments for the full process. For finer-grained canary control at the per-request level, combine Route 53 weighted routing with ALB weighted target groups.

Health checks and TTL: how failover actually works

Health checks

Route 53 health checks continuously probe your endpoints from multiple AWS locations. You configure the endpoint URL or IP, the protocol (HTTP/HTTPS/TCP), the check interval (10 or 30 seconds), and the failure threshold, meaning how many consecutive failures trigger a status change.

When you set EvaluateTargetHealth: true on an alias record, Route 53 inherits the health of the target resource. If the ALB the record points to has no healthy targets registered, Route 53 treats the entire record as unhealthy and excludes it from routing decisions automatically.

For complex conditions, you can use calculated health checks that aggregate multiple child health checks, for example: “treat this region as healthy only if at least 2 of 3 backend health checks are passing.”

TTL and failover speed

TTL (Time to Live) controls how long DNS resolvers and clients cache a DNS answer. The practical consequence for failover:

• High TTL (e.g., 300s): Faster DNS resolution under normal conditions, but slower failover. Clients may keep hitting a failed endpoint for up to 5 minutes.
• Low TTL (e.g., 30-60s): Clients refresh DNS quickly after a failover event, at the cost of slightly more DNS query volume.

For failover records: use TTL 30-60 seconds. For stable latency or geolocation records: TTL 60-300 seconds is a reasonable balance. Some DNS resolvers do not honor TTLs exactly; a small percentage of users may see stale responses longer than your TTL suggests.

If you are setting up Route 53 for the first time, see Route 53 setup for a step-by-step walkthrough.