Back to Route 53 & DNS
Q1Question 1 of 1

Route 53, Routing Policies, and Health-Check-Driven Failover

Key Concepts
  • Route 53 is AWS's highly available authoritative DNS service that translates domain names into IP addresses or resource targets.
  • Routing policies decide which answer to return: simple, weighted, latency-based, failover, geolocation, geoproximity, and multivalue.
  • Weighted routing splits traffic by percentages, ideal for canary releases where ten percent of traffic goes to a new version.
  • Failover routing returns the primary while healthy and switches to the secondary when the health check fails.
  • Health checks probe endpoints from multiple locations and mark them unhealthy when enough probes fail, triggering automatic traffic shifts.
  • DNS caching means failover speed depends on the record's TTL, so failover records should use a low TTL like sixty seconds.

Definition

Route 53 is smart DNS that returns the best answer by policy and automatically stops handing out the address of anything a health check says is down.
  • Route 53 – AWS's highly available, scalable authoritative DNS service that translates domain names into IP addresses or AWS resource targets.
  • Routing policy – the logic that decides which DNS answer to return: simple, weighted, latency-based, failover, geolocation, geoproximity, or multivalue answer.
  • Health check – a probe that Route 53 runs from multiple locations to verify an endpoint is healthy; when it reports unhealthy, Route 53 stops returning that target.
  • TTL (Time to Live) – how long resolvers cache a DNS answer; failover records use a low TTL so clients re-query quickly after a target goes down.

Think of Route 53 as the telephone directory and call-routing desk of National Bank of India combined. When Rajesh asks "what is the number for internet banking?", the desk looks it up and gives him a number. But the desk is smart: it can give different customers different numbers based on rules -- the nearest branch, a branch that is not overloaded, or a backup branch if the main one is closed. The health check is the desk constantly phoning each branch to ask "are you open?", and if a branch does not answer, the desk simply stops giving out that branch's number.

Understanding the Concepts

What is Route 53?

Route 53 is authoritative DNS. It holds the records for your domain in a hosted zone and answers queries from resolvers worldwide. You register domains, create hosted zones, and configure records that map names to targets. The routing policy on each record is the brain that decides which value to return.

JAVA
// Hosted zone and record concept
package com.bank.infrastructure;

public class Route53HostedZone {
    private final String domain = "bank.example.com";
    private final String hostedZoneId = "Z1234567890";

    public void explain() {
        System.out.println("Hosted Zone: " + domain);
        System.out.println("  Contains all DNS records for this domain");
        System.out.println("  Route 53 answers queries from global resolvers");
    }
}

What is simple routing?

The simple policy returns one record, or a random one among several values, with no logic. You use it for a single resource like one server or one load balancer.

JAVA
// Simple routing: one endpoint, no conditions
package com.bank.infrastructure;

public class SimpleRoutingExample {
    public static String resolve() {
        return "52.10.1.100"; // single value, no logic
    }
}

What is weighted routing?

The weighted policy splits traffic by assigned weights. If the bank wants to send ten percent of traffic to a new version for a canary release, it gives the new target a weight of 10 and the old one a weight of 90. Route 53 returns the target proportional to its weight.

JAVA
// Weighted routing: canary release split
package com.bank.infrastructure;

import java.util.List;
import java.util.Random;

public class WeightedRoutingSimulator {
    record WeightedTarget(String endpoint, int weight) {}

    private static final List<WeightedTarget> TARGETS = List.of(
        new WeightedTarget("v1.bank.example.com", 90),
        new WeightedTarget("v2.bank.example.com", 10)
    );

    public static String route() {
        int total = TARGETS.stream().mapToInt(WeightedTarget::weight).sum();
        int rand = new Random().nextInt(total);
        int cumulative = 0;
        for (WeightedTarget t : TARGETS) {
            cumulative += t.weight();
            if (rand < cumulative) return t.endpoint();
        }
        return TARGETS.getLast().endpoint();
    }
}

What is latency-based routing?

The latency-based policy returns the Region that gives the lowest network latency to the user. A customer in Mumbai is sent to ap-south-1 and a customer in Europe to eu-west-1. Route 53 measures latency data between users and AWS Regions and uses it to make the decision.

JAVA
// Latency-based routing: lowest latency to user
package com.bank.infrastructure;

import java.util.Map;

public class LatencyRoutingSimulator {
    private static final Map<String, String> REGION_ENDPOINTS = Map.of(
        "ap-south-1", "mumbai-alb.bank.example.com",
        "eu-west-1",  "dublin-alb.bank.example.com",
        "us-east-1",  "virginia-alb.bank.example.com"
    );

    public static String route(String closestRegion) {
        return REGION_ENDPOINTS.getOrDefault(closestRegion, "mumbai-alb.bank.example.com");
    }
}

What is failover routing and how do health checks drive it?

The failover policy has a primary and a secondary. It returns the primary while the primary's health check is healthy, and switches to the secondary the moment the primary is reported unhealthy. This is the classic active-passive disaster recovery setup.

A health check in Route 53 periodically probes an endpoint (for example an HTTPS call to /health) from multiple AWS locations. If enough checks fail, the health check flips to unhealthy, and Route 53 immediately stops returning the unhealthy value.

JAVA
// Failover routing concept
package com.bank.infrastructure;

public class FailoverRoutingSimulator {
    private final String primary = "mumbai-alb.bank.example.com";
    private final String secondary = "singapore-alb.bank.example.com";
    private boolean primaryHealthy = true;

    public String route() {
        if (primaryHealthy) {
            return primary;
        }
        System.out.println("Primary unhealthy! Failing over to secondary.");
        return secondary;
    }

    public void healthCheckFailed() {
        this.primaryHealthy = false;
    }
}

What are geolocation and geoproximity routing?

The geolocation policy routes by the user's physical location (country, continent). The bank uses this for compliance -- Indian users must be served from Indian infrastructure for RBI data-residency rules. If no match is found, a default record is returned.

The geoproximity policy routes by geographic distance between the user and the resource, with a bias value that lets you expand or shrink a resource's catchment area.

JAVA
// Geolocation routing for data-residency compliance
package com.bank.infrastructure;

import java.util.Map;

public class GeolocationRoutingSimulator {
    private static final Map<String, String> COUNTRY_ENDPOINTS = Map.of(
        "IN", "mumbai-alb.bank.example.com",     // RBI compliance: India -> India
        "SG", "singapore-alb.bank.example.com"
    );
    private static final String DEFAULT = "mumbai-alb.bank.example.com";

    public static String route(String countryCode) {
        return COUNTRY_ENDPOINTS.getOrDefault(countryCode, DEFAULT);
    }
}

What is multivalue answer routing?

The multivalue answer policy returns up to eight healthy records at random, giving simple client-side load spreading with health checking. It is a lightweight alternative to a load balancer for distributing traffic across a handful of endpoints, but it is not a replacement for proper load balancing.

JAVA
// Multivalue answer: return multiple healthy records
package com.bank.infrastructure;

import java.util.List;
import java.util.stream.Collectors;

public class MultivalueRoutingSimulator {
    record Endpoint(String ip, boolean healthy) {}

    private static final List<Endpoint> ENDPOINTS = List.of(
        new Endpoint("52.10.1.100", true),
        new Endpoint("52.10.2.200", true),
        new Endpoint("52.10.3.300", false) // unhealthy, excluded
    );

    public static List<String> resolve() {
        return ENDPOINTS.stream()
            .filter(Endpoint::healthy)
            .map(Endpoint::ip)
            .collect(Collectors.toList());
    }
}

Why does TTL matter for failover speed?

Because DNS answers are cached for the record's TTL, failover is not instant -- it is only as fast as the TTL allows. On failover records I set a low TTL like sixty seconds so clients re-query quickly and recover fast. This trades slightly more DNS traffic for faster recovery.

JAVA
// TTL impact on failover speed
package com.bank.infrastructure;

public class TtlFailoverExplainer {
    public static void main(String[] args) {
        System.out.println("TTL = 300 seconds (5 minutes):");
        System.out.println("  Failover takes up to 5 min (clients cache old answer)");
        System.out.println();
        System.out.println("TTL = 60 seconds (1 minute):");
        System.out.println("  Failover takes up to 1 min (clients re-query quickly)");
        System.out.println("  Trade-off: more DNS queries per minute");
        System.out.println();
        System.out.println("Rule: use low TTL (60s) on failover records.");
    }
}

What should a senior engineer know?

Routing policies can be combined through record aliasing. You can have a latency-based record that points to failover records in each Region, giving you both nearest-Region routing and per-Region disaster recovery. Health checks can also monitor CloudWatch alarms, not just endpoints, which lets you fail over based on any custom metric.

Visual Overview

DIAGRAM
            Route 53 Routing Policies Overview

  ┌──────────────────────────────────────────────────────────┐
  │                    DNS Query                              │
  │           "What is bank.example.com?"                     │
  └─────────────────────────┬────────────────────────────────┘
                            │
                            ▼
  ┌─────────────────────────────────────────────────────────┐
  │               Route 53 Routing Policy                   │
  │                                                         │
  │  Simple:       → return one record                      │
  │  Weighted:     → split by weight (90/10 canary)         │
  │  Latency:      → lowest latency Region                  │
  │  Failover:     → primary if healthy, else secondary     │
  │  Geolocation:  → user's country (compliance)            │
  │  Geoproximity: → geographic distance + bias             │
  │  Multivalue:   → up to 8 healthy records                │
  └─────────────────────────┬───────────────────────────────┘
                            │
                            ▼
  ┌─────────────────────────────────────────────────────────┐
  │               Health Check Integration                  │
  │                                                         │
  │  Route 53 probes endpoints from multiple locations.     │
  │  If primary fails -> stops returning it.                │
  │  Traffic shifts to healthy target automatically.        │
  │                                                         │
  │  ┌─────────┐  healthy   ┌─────────┐                    │
  │  │ Mumbai  │───────────→│ Return  │                    │
  │  │ /health │  200 OK    │ Mumbai  │                    │
  │  └─────────┘            └─────────┘                    │
  │                                                         │
  │  ┌─────────┐  unhealthy ┌─────────┐                    │
  │  │ Mumbai  │───────────→│ Return  │                    │
  │  │ /health │  timeout   │Singapore│  (failover)        │
  │  └─────────┘            └─────────┘                    │
  └─────────────────────────────────────────────────────────┘

Key Takeaway

Amazon Route 53 is AWS's managed, highly available authoritative DNS service. Its job is to answer DNS queries, turning a name like our internet banking domain into the right target, and what makes it powerful is that it returns a different best answer depending on the routing policy. Simple returns one value. Weighted splits traffic by percentages for canary releases. Latency-based sends each user to the nearest Region. Failover returns the primary while healthy and the secondary when not. Geolocation routes by country for data-residency compliance. Geoproximity routes by distance with a tunable bias. Multivalue returns several healthy records for lightweight client-side load spreading.

The piece that ties disaster recovery together is the health check. Route 53 continuously probes an endpoint from multiple locations, and when enough probes fail it marks that target unhealthy. When a record is attached to a failover or multivalue policy, Route 53 immediately stops returning the unhealthy value, so traffic shifts automatically without any human editing DNS.

The nuance I always raise is DNS caching. Because resolvers cache answers for the record's TTL, failover is only as fast as that TTL allows, so on failover records I set a low TTL like sixty seconds so clients re-query quickly and recover fast, accepting slightly more DNS traffic as the trade-off.

At National Bank of India I ran internet banking active-passive across the Mumbai and Singapore Regions. I configured a Route 53 failover policy with a health check on the Mumbai endpoint and a low TTL. When Mumbai became unreachable during an incident, Route 53 detected the failed health checks and started returning Singapore automatically, so customers were back online within about a minute. For releases I used weighted routing for canary deploys, and for RBI data-residency I used geolocation routing to keep Indian users on Indian infrastructure.

Remember one sentence: Route 53 routing policies decide which DNS answer to return, and health checks automatically stop returning unhealthy targets, so failover happens at the DNS level with no human intervention.

---

Share