---
title: "Global Load Balancing and Geo-Routing: DNS GSLB, Anycast, and Cloud Provider Configurations"
description: "Practical guide to global server load balancing covering DNS-based GSLB, anycast vs unicast, failover routing, latency-based routing, geolocation routing, Cloudflare Load Balancing, AWS Global Accelerator, GCP external HTTP(S) load balancing, and real configuration examples for each approach."
url: https://agent-zone.ai/knowledge/infrastructure/global-load-balancing/
section: knowledge
date: 2026-02-22
categories: ["infrastructure"]
tags: ["gslb","global-load-balancing","anycast","geo-routing","route53","cloudflare","global-accelerator","latency-routing","failover","dns"]
skills: ["global-traffic-management","dns-routing","cloud-load-balancing","geo-routing-design"]
tools: ["terraform","aws-cli","gcloud","cloudflare-cli","dig","curl"]
levels: ["intermediate","advanced"]
word_count: 1292
formats:
  json: https://agent-zone.ai/knowledge/infrastructure/global-load-balancing/index.json
  html: https://agent-zone.ai/knowledge/infrastructure/global-load-balancing/?format=html
  api: https://api.agent-zone.ai/api/v1/knowledge/search?q=Global+Load+Balancing+and+Geo-Routing%3A+DNS+GSLB%2C+Anycast%2C+and+Cloud+Provider+Configurations
---


## DNS-Based Global Server Load Balancing

Global server load balancing (GSLB) directs users to the nearest or healthiest regional deployment. The most common approach is DNS-based: the authoritative DNS server returns different IP addresses depending on the querying client's location, the health of backend regions, or configured routing policies.

When a user resolves `app.example.com`, the GSLB-aware DNS server considers the user's location (inferred from the resolver's IP or EDNS Client Subnet), the health of each regional endpoint, and the configured routing policy. It returns the IP address of the best region for that user.

```
User in Tokyo → DNS query for app.example.com
  → GSLB DNS sees: source = Asia-Pacific
  → Checks health: ap-northeast-1 healthy, us-east-1 healthy
  → Policy: latency-based
  → Returns: 54.x.x.x (ap-northeast-1 endpoint)

User in New York → DNS query for app.example.com
  → GSLB DNS sees: source = US-East
  → Returns: 34.x.x.x (us-east-1 endpoint)
```

The limitation of DNS-based GSLB is caching. Once a DNS response is cached (at the recursive resolver, OS, or application level), the routing decision is locked until the TTL expires. A region can fail, but clients with cached DNS responses will continue hitting it until the cache expires.

## Anycast vs Unicast

**Unicast**: each IP address is announced from exactly one location. Traditional routing -- one IP, one destination. DNS GSLB works with unicast by returning different IPs for different regions.

**Anycast**: the same IP address is announced from multiple locations via BGP. The network routes packets to the nearest location based on BGP path length. No DNS involved in the routing decision -- the network handles it.

Anycast advantages: instant failover (BGP reconverges in seconds when a location goes down), no DNS TTL delays, and the user always hits the nearest location without any DNS-level logic. CDNs (Cloudflare, AWS CloudFront) and DNS providers (Cloudflare DNS, Google Public DNS) use anycast extensively.

Anycast limitation: it works best for stateless protocols like DNS or HTTP request/response. For TCP-based connections, a BGP route change mid-connection can cause the connection to be routed to a different location, breaking it. This is why anycast is typically paired with TCP termination at the edge (the edge proxy handles the anycast routing, then establishes a stable backend connection).

```
Unicast:
  User → DNS returns region-specific IP → Routed to that specific region

Anycast:
  User → DNS returns anycast IP (same IP everywhere)
       → Network routes to nearest location via BGP
       → If location fails, BGP reconverges → traffic shifts automatically
```

## Routing Policies

**Failover routing**: a primary endpoint serves all traffic. If health checks detect the primary is down, DNS returns the secondary endpoint. Use this for active-passive setups where you want automatic DNS failover.

**Latency-based routing**: DNS returns the endpoint with the lowest latency to the querying resolver. AWS Route53 measures latency between its resolver network and each endpoint's region, then routes accordingly. Best for active-active deployments where you want users to hit the nearest healthy region.

**Geolocation routing**: routes based on the geographic location of the user. "Users in Europe go to eu-west-1, users in Asia go to ap-southeast-1, everyone else goes to us-east-1." Useful for data sovereignty requirements where data must stay in a specific region.

**Weighted routing**: distributes traffic across endpoints according to configured weights. "Send 90% to us-east-1, 10% to us-west-2." Used for gradual migrations, canary deployments, and blue-green traffic shifting.

**Geoproximity routing** (Route53 Traffic Flow): like geolocation but with a bias parameter. You can expand or shrink the geographic area that routes to each endpoint. Useful for fine-tuning when geographic boundaries do not align with your deployment regions.

## AWS Route53 Configuration

Route53 supports all routing policies natively. Here is a latency-based setup with health checks:

```hcl
resource "aws_route53_health_check" "us_east" {
  fqdn              = "us-east.app.example.com"
  port               = 443
  type               = "HTTPS"
  resource_path      = "/healthz"
  failure_threshold  = 3
  request_interval   = 10

  tags = { Name = "us-east-health-check" }
}

resource "aws_route53_health_check" "eu_west" {
  fqdn              = "eu-west.app.example.com"
  port               = 443
  type               = "HTTPS"
  resource_path      = "/healthz"
  failure_threshold  = 3
  request_interval   = 10

  tags = { Name = "eu-west-health-check" }
}

resource "aws_route53_record" "app_us" {
  zone_id        = aws_route53_zone.main.zone_id
  name           = "app.example.com"
  type           = "A"
  set_identifier = "us-east"

  latency_routing_policy {
    region = "us-east-1"
  }

  alias {
    name                   = aws_lb.us_east.dns_name
    zone_id                = aws_lb.us_east.zone_id
    evaluate_target_health = true
  }

  health_check_id = aws_route53_health_check.us_east.id
}

resource "aws_route53_record" "app_eu" {
  zone_id        = aws_route53_zone.main.zone_id
  name           = "app.example.com"
  type           = "A"
  set_identifier = "eu-west"

  latency_routing_policy {
    region = "eu-west-1"
  }

  alias {
    name                   = aws_lb.eu_west.dns_name
    zone_id                = aws_lb.eu_west.zone_id
    evaluate_target_health = true
  }

  health_check_id = aws_route53_health_check.eu_west.id
}
```

Route53 health checks cost $0.50/month per endpoint (HTTP) or $1.00/month (HTTPS) per AWS health checker. With health checkers in multiple regions, a single HTTPS health check costs approximately $1-2/month.

## Cloudflare Load Balancing

Cloudflare's load balancer operates at the edge, combining DNS-level routing with its anycast network. It supports origin pools, health monitors, and steering policies.

```
Pool Setup (via API):
POST /zones/{zone_id}/load_balancers/pools
{
  "name": "us-east-pool",
  "origins": [
    { "name": "us-east-1", "address": "us-east.app.example.com", "enabled": true }
  ],
  "monitor": "{monitor_id}"
}

Health Monitor:
POST /zones/{zone_id}/load_balancers/monitors
{
  "type": "https",
  "expected_codes": "200",
  "path": "/healthz",
  "interval": 60,
  "timeout": 5,
  "retries": 2,
  "follow_redirects": true
}

Load Balancer:
POST /zones/{zone_id}/load_balancers
{
  "name": "app.example.com",
  "default_pools": ["{us-east-pool-id}", "{eu-west-pool-id}"],
  "fallback_pool": "{us-east-pool-id}",
  "steering_policy": "geo",
  "pop_pools": {
    "FRA": ["{eu-west-pool-id}"],
    "IAD": ["{us-east-pool-id}"]
  }
}
```

Cloudflare pricing: the load balancing add-on starts at $5/month for 2 origins and 5 health check regions, plus $5/month per additional origin. For a two-region active-active setup, expect $10-15/month.

## AWS Global Accelerator

Global Accelerator provides anycast IP addresses that route traffic over the AWS backbone network to the nearest healthy regional endpoint. Unlike DNS-based routing, it does not depend on DNS TTL -- BGP reroutes traffic in seconds when a region fails.

```hcl
resource "aws_globalaccelerator_accelerator" "app" {
  name            = "app-accelerator"
  ip_address_type = "IPV4"
  enabled         = true
}

resource "aws_globalaccelerator_listener" "app" {
  accelerator_arn = aws_globalaccelerator_accelerator.app.id
  protocol        = "TCP"

  port_range {
    from_port = 443
    to_port   = 443
  }
}

resource "aws_globalaccelerator_endpoint_group" "us_east" {
  listener_arn          = aws_globalaccelerator_listener.app.id
  endpoint_group_region = "us-east-1"
  health_check_path     = "/healthz"
  health_check_protocol = "HTTPS"

  endpoint_configuration {
    endpoint_id = aws_lb.us_east.arn
    weight      = 100
  }
}

resource "aws_globalaccelerator_endpoint_group" "eu_west" {
  listener_arn          = aws_globalaccelerator_listener.app.id
  endpoint_group_region = "eu-west-1"
  health_check_path     = "/healthz"
  health_check_protocol = "HTTPS"

  endpoint_configuration {
    endpoint_id = aws_lb.eu_west.arn
    weight      = 100
  }
}
```

Global Accelerator costs $0.025/hour (~$18/month) per accelerator plus $0.015-0.035/GB data transfer (varies by region). For moderate traffic (1TB/month), total cost is roughly $33-53/month. More expensive than DNS-based routing but provides faster failover and consistent latency improvement by keeping traffic on the AWS backbone.

## GCP External HTTP(S) Load Balancer

GCP's external HTTP(S) load balancer is global by default. It uses anycast and Google's backbone network to route traffic to the nearest healthy backend, making it the closest thing to a built-in GSLB.

```hcl
resource "google_compute_health_check" "app" {
  name               = "app-health-check"
  check_interval_sec = 10
  timeout_sec        = 5

  https_health_check {
    port         = 443
    request_path = "/healthz"
  }
}

resource "google_compute_backend_service" "app" {
  name                  = "app-backend"
  protocol              = "HTTPS"
  health_checks         = [google_compute_health_check.app.id]
  load_balancing_scheme = "EXTERNAL_MANAGED"

  backend {
    group           = google_compute_region_instance_group_manager.us.instance_group
    balancing_mode  = "UTILIZATION"
    max_utilization = 0.8
  }

  backend {
    group           = google_compute_region_instance_group_manager.eu.instance_group
    balancing_mode  = "UTILIZATION"
    max_utilization = 0.8
  }
}
```

GCP's global LB does not require separate GSLB configuration -- it routes to the nearest healthy backend automatically. This makes it the simplest multi-region setup among the major cloud providers, but it locks you into GCP's load balancing ecosystem.

## Choosing the Right Approach

Use **DNS-based GSLB** (Route53, Cloudflare) when: you need multi-cloud or hybrid routing, you want provider flexibility, and you can tolerate DNS TTL-based failover timing (30-300 seconds).

Use **anycast-based** (Global Accelerator, GCP global LB) when: you need sub-second failover, consistent latency improvement, and you are single-cloud. The cost premium is justified when DNS TTL delays are unacceptable.

Use **Cloudflare Load Balancing** when: you already use Cloudflare for CDN/WAF, you need a simple multi-cloud GSLB without managing DNS routing policies directly, and the origin count is small enough to keep costs reasonable.