Route 53 Latency-Based Routing for Multi-Region MCP Servers

Creating latency records for a multi-region MCP server deployment

Each latency record associates the DNS name with an AWS region. Route 53 maintains latency data between its edge probers and each AWS region, and uses that data to select the lowest-latency region for each incoming DNS query:

import boto3, uuid

route53 = boto3.client("route53")

# MCP server endpoints in three AWS regions
REGIONAL_ENDPOINTS = {
    "us-east-1": {
        "ip": "203.0.113.10",
        "alb_dns": "mcp-us-east-1.us-east-1.elb.amazonaws.com",
        "alb_zone_id": "Z35SXDOTRQ7X7K",
    },
    "eu-west-1": {
        "ip": "203.0.113.11",
        "alb_dns": "mcp-eu-west-1.eu-west-1.elb.amazonaws.com",
        "alb_zone_id": "Z32O12XQLNTSW2",
    },
    "ap-southeast-1": {
        "ip": "203.0.113.12",
        "alb_dns": "mcp-apac.ap-southeast-1.elb.amazonaws.com",
        "alb_zone_id": "Z1LMS91P8CMLE5",
    },
}

for region, endpoint in REGIONAL_ENDPOINTS.items():
    # Create a health check for this regional endpoint
    hc = route53.create_health_check(
        CallerReference=str(uuid.uuid4()),
        HealthCheckConfig={
            "Type": "HTTPS",
            "FullyQualifiedDomainName": "mcp.example.com",
            "IPAddress": endpoint["ip"],  # probe the regional IP directly
            "Port": 443,
            "ResourcePath": "/health",
            "RequestInterval": 30,
            "FailureThreshold": 3,
            "EnableSNI": True,
            # Restrict probers to the same region for more accurate measurements
            "Regions": [
                region,
                # Add adjacent region for redundant probing
            ],
        },
    )
    hc_id = hc["HealthCheck"]["Id"]

    # Create a latency Alias record pointing at the regional ALB
    route53.change_resource_record_sets(
        HostedZoneId=HOSTED_ZONE_ID,
        ChangeBatch={
            "Changes": [{
                "Action": "UPSERT",
                "ResourceRecordSet": {
                    "Name": "mcp.example.com",
                    "Type": "A",
                    # SetIdentifier: unique per record set within the same name+type
                    "SetIdentifier": f"mcp-latency-{region}",
                    # Region: the AWS region this record routes to
                    # Route 53 selects the record with lowest measured latency from resolver
                    "Region": region,
                    "AliasTarget": {
                        "DNSName": endpoint["alb_dns"],
                        "HostedZoneId": endpoint["alb_zone_id"],
                        "EvaluateTargetHealth": True,
                    },
                    # Health check excludes this region if its endpoint is unhealthy
                    "HealthCheckId": hc_id,
                }
            }]
        }
    )
    print(f"Created latency record for {region}: {endpoint['alb_dns']}")

With three latency records, Route 53 routes each DNS query to whichever of us-east-1, eu-west-1, or ap-southeast-1 has the lowest measured latency from the querying resolver. When a regional health check fails, Route 53 excludes that region and routes queries to the next-lowest-latency available region.

How Route 53 latency measurements work

Route 53 latency routing is based on latency data that AWS measures internally — not real-time per-query measurements:

# Route 53 latency routing — what it measures and when:
#
# Source: Route 53 measures round-trip time from its edge locations to each
#         AWS region's endpoint infrastructure. This is a periodic background
#         measurement, not a per-query real-time probe.
#
# Resolver-to-region: Route 53 uses the resolver's IP address to determine
#         its approximate location (country/region), then looks up which AWS
#         region has the lowest measured latency from that location.
#
# Update frequency: latency data is updated on the order of minutes.
#         It does not reflect transient network conditions (e.g., a 5-second
#         spike in cross-Atlantic latency does not immediately re-route traffic).
#
# Geographic approximation: Route 53 maps each resolver IP to a location,
#         but EDNS0 Client Subnet (ECS) is used when available — resolvers
#         that send ECS headers allow Route 53 to route based on the actual
#         client subnet rather than the resolver's datacenter IP.
#
# Implication for MCP deployments:
# - Latency routing works well for routing US users to us-east-1 and
#   European users to eu-west-1 — the geographic gap is large enough that
#   the latency differential is stable and meaningful.
# - Latency routing does NOT reliably distinguish between us-east-1 and
#   us-east-2 from a US-based client — the latency gap is too small and
#   the measurement noise too high.
# - For within-region redundancy, use ALB multi-AZ target groups, not
#   Route 53 latency routing.

# Verify actual latency differential before deploying multi-region:
# From a US-East client, measure both endpoints:
# curl -o /dev/null -s -w "%{time_total}\n" https://mcp-us-east-1.example.com/health
# curl -o /dev/null -s -w "%{time_total}\n" https://mcp-eu-west-1.example.com/health
# If the gap is <50ms, the operational overhead of multi-region probably is not worth it

Session stickiness: the DNS caching problem for MCP latency routing

MCP clients that resolve the server hostname once and reuse the cached IP for the entire session will not benefit from latency re-routing during a session. This is a fundamental constraint of DNS-level routing:

# Sequence of events for a long-running MCP agent session:
#
# T=0:    Agent starts, resolves mcp.example.com → 203.0.113.10 (us-east-1)
# T=0:    Agent connects to 203.0.113.10, establishes MCP session
# T=0..N: All tool calls go to 203.0.113.10 (no re-resolution)
# T=N:    Route 53 latency data shifts, now routes new queries to eu-west-1
# T=N:    NEW agents starting now would go to eu-west-1
# T=N:    EXISTING agent continues on 203.0.113.10 until session ends
#
# Implications for MCP server operators:
# 1. Latency routing benefits NEW connections, not in-flight sessions
# 2. Session length determines how quickly the routing shift takes effect
# 3. For long-lived MCP sessions (hours), latency routing provides no
#    benefit for in-flight sessions — only after reconnect
#
# Solution for session-level latency optimization:
# - Use AWS Global Accelerator instead of Route 53 latency routing
# - Global Accelerator provides anycast IPs (traffic routes via AWS
#   backbone from the nearest AWS edge PoP) for the full session duration
# - MCP sessions benefit from the AWS network backbone for every packet,
#   not just the first DNS resolution
#
# Global Accelerator vs Route 53 latency routing for MCP servers:
# Route 53: free DNS routing, no session-level routing, ~100ms detection lag
# Global Accelerator: ~$0.025/hr + $0.01/GB, per-packet routing, instant failover
# Use Global Accelerator when P99 latency per tool call matters at global scale

Geolocation routing: routing by country or continent

When data sovereignty requires that clients in a specific country always hit a specific regional deployment, use geolocation routing instead of latency routing:

# Geolocation routing: route based on client location (country/continent)
# Use case: EU clients must hit eu-west-1 (data residency / GDPR)
#           US clients must hit us-east-1
#           Everyone else hits a default record

# EU record — all EU country codes route to eu-west-1
route53.change_resource_record_sets(
    HostedZoneId=HOSTED_ZONE_ID,
    ChangeBatch={
        "Changes": [{
            "Action": "UPSERT",
            "ResourceRecordSet": {
                "Name": "mcp.example.com",
                "Type": "A",
                "SetIdentifier": "mcp-geo-eu",
                "GeoLocation": {
                    "ContinentCode": "EU",  # All European countries
                },
                "TTL": 60,
                "ResourceRecords": [{"Value": "203.0.113.11"}],  # eu-west-1
                "HealthCheckId": eu_hc_id,
            }
        }]
    }
)

# US record — US clients → us-east-1
route53.change_resource_record_sets(
    HostedZoneId=HOSTED_ZONE_ID,
    ChangeBatch={
        "Changes": [{
            "Action": "UPSERT",
            "ResourceRecordSet": {
                "Name": "mcp.example.com",
                "Type": "A",
                "SetIdentifier": "mcp-geo-us",
                "GeoLocation": {
                    "CountryCode": "US",
                },
                "TTL": 60,
                "ResourceRecords": [{"Value": "203.0.113.10"}],  # us-east-1
                "HealthCheckId": us_hc_id,
            }
        }]
    }
)

# Default record — required for geolocation routing
# Catches all countries not explicitly listed
route53.change_resource_record_sets(
    HostedZoneId=HOSTED_ZONE_ID,
    ChangeBatch={
        "Changes": [{
            "Action": "UPSERT",
            "ResourceRecordSet": {
                "Name": "mcp.example.com",
                "Type": "A",
                "SetIdentifier": "mcp-geo-default",
                "GeoLocation": {
                    "CountryCode": "*",  # wildcard: all other countries
                },
                "TTL": 60,
                "ResourceRecords": [{"Value": "203.0.113.10"}],  # default to us-east-1
                "HealthCheckId": us_hc_id,
            }
        }]
    }
)

# Note: if the geolocation-matched record's health check fails,
# Route 53 does NOT fall back to the default record automatically —
# it returns the geolocation record anyway (to prevent cross-border routing).
# For compliance-driven geolocation routing, this is the correct behavior:
# an EU client should never be routed to a US endpoint, even during an outage.
# Use the secondary record in a separate failover policy at the region level.

Combining latency routing with failover using policy records

Route 53 Traffic Flow (policy records) enables layered routing: latency routing at the top level selects the best region, then failover routing within each region handles per-region high availability. This requires the Traffic Flow feature, which is billed separately ($50/month per policy record per hosted zone):

# Without Traffic Flow, combine latency + failover using the
# "health-check on latency records" pattern:
#
# Each regional latency record has a health check attached.
# When a region's health check fails, Route 53 excludes it from latency routing
# and sends traffic to the next-lowest-latency healthy region.
#
# For in-region failover (primary/secondary within a region):
# Create the regional latency record pointing at a regional ALB.
# The ALB routes across multiple AZs and healthy targets automatically.
# This handles single-AZ or single-instance failures within a region
# without needing a separate Route 53 failover record for each region.
#
# Architecture:
#   Route 53 latency record (us-east-1) → ALB (us-east-1)
#                                              ├→ ECS task (us-east-1a) ✓
#                                              └→ ECS task (us-east-1b) ✗ (failed)
#   Route 53 latency record (eu-west-1) → ALB (eu-west-1) ✓
#   Route 53 latency record (ap-southeast-1) → ALB (ap-southeast-1) ✓
#
# If the entire us-east-1 ALB is unhealthy (Route 53 health check fails),
# traffic shifts to eu-west-1 or ap-southeast-1 based on latency.
# Within us-east-1, if one ECS task fails, the ALB handles it without
# any Route 53 change needed.

# Practical recommendation for most MCP deployments:
# One latency record per region → ALB per region → ECS multi-AZ target group
# This covers: cross-region latency optimization + per-region HA + in-region failover