Route 53’s Geoproximity routing isn’t about where your users are, but where you want to send them.
Let’s watch it in action. Imagine you have two identical web servers, one in us-east-1 and another in eu-west-1. You want to direct traffic from North America to the us-east-1 instance and from Europe to the eu-west-1 instance, but with a twist: you want to bias some traffic from the US towards Europe, even if the US instance is closer.
Here’s how you’d set that up in Route 53:
First, create a health check for each of your endpoints. This is crucial because Geoproximity routing relies on health checks to determine which endpoints are available.
aws route53 create-health-check --caller-reference geoproximity-us-east-1-$(date +%s) --health-check-config IPAddress=<IP_OF_US_SERVER>,Port=80,Type=HTTP,RequestInterval=30,FailureThreshold=3,ThresholdCount=3
aws route53 create-health-check --caller-reference geoproximity-eu-west-1-$(date +%s) --health-check-config IPAddress=<IP_OF_EU_SERVER>,Port=80,Type=HTTP,RequestInterval=30,FailureThreshold=3,ThresholdCount=3
Now, create a Geoproximity routing policy for your domain, say example.com. You’ll associate each endpoint with a specific geographic region and a bias value. The bias is an integer from -100 to 100. A positive bias means you want to send more traffic to this endpoint from the specified region, while a negative bias means you want to send less. A bias of 0 means no preference.
# Get the Health Check IDs from the previous step
US_HC_ID=$(aws route53 list-health-checks --query "HealthChecks[?CallerReference=='geoproximity-us-east-1-YOUR_TIMESTAMP'].Id" --output text)
EU_HC_ID=$(aws route53 list-health-checks --query "HealthChecks[?CallerReference=='geoproximity-eu-west-1-YOUR_TIMESTAMP'].Id" --output text)
aws route53 change-resource-record-sets --hosted-zone-id YOUR_HOSTED_ZONE_ID --change-batch '{
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "example.com",
"Type": "A",
"SetIdentifier": "us-east-1-primary",
"TTL": 60,
"GeoproximityRoutingPolicy": {
"HealthCheckId": "'$US_HC_ID'",
"Bias": 0,
"Region": "us-east-1"
},
"ResourceRecords": [
{
"Value": "<IP_OF_US_SERVER>"
}
]
}
},
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "example.com",
"Type": "A",
"SetIdentifier": "eu-west-1-primary",
"TTL": 60,
"GeoproximityRoutingPolicy": {
"HealthCheckId": "'$EU_HC_ID'",
"Bias": 0,
"Region": "eu-west-1"
},
"ResourceRecords": [
{
"Value": "<IP_OF_EU_SERVER>"
}
]
}
}
]
}'
Now, let’s introduce the bias. Suppose you want to send 20% more traffic from North America to your European endpoint. You’d adjust the Bias for the eu-west-1 endpoint when a request originates from us-east-1.
aws route53 change-resource-record-sets --hosted-zone-id YOUR_HOSTED_ZONE_ID --change-batch '{
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "example.com",
"Type": "A",
"SetIdentifier": "us-east-1-primary",
"TTL": 60,
"GeoproximityRoutingPolicy": {
"HealthCheckId": "'$US_HC_ID'",
"Bias": 0,
"Region": "us-east-1"
},
"ResourceRecords": [
{
"Value": "<IP_OF_US_SERVER>"
}
]
}
},
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "example.com",
"Type": "A",
"SetIdentifier": "eu-west-1-primary",
"TTL": 60,
"GeoproximityRoutingPolicy": {
"HealthCheckId": "'$EU_HC_ID'",
"Bias": 20, // Increased bias for European endpoint
"Region": "eu-west-1"
},
"ResourceRecords": [
{
"Value": "<IP_OF_EU_SERVER>"
}
]
}
}
]
}'
In this scenario, when a DNS query comes from a resolver in the us-east-1 region (which Route 53 typically maps to North America), it will consider the us-east-1 endpoint with a bias of 0 and the eu-west-1 endpoint with a bias of 20. Route 53’s algorithm will then distribute traffic. A bias of 20 effectively nudges 20% more traffic towards the eu-west-1 endpoint than it would receive with a bias of 0, even though the us-east-1 endpoint is geographically closer. You can also use negative bias to send less traffic to an endpoint.
The Region field in the GeoproximityRoutingPolicy is not about the actual location of the DNS resolver making the request. Instead, it’s a hint to Route 53 about which geographic area you want to associate this endpoint with. Route 53 then uses this Region and the Bias to influence traffic distribution for resolvers that fall within that conceptual region. It’s a way to say, "For users I consider to be in North America, I want to favor my European endpoint slightly."
The core mechanism for Route 53 to determine a user’s "location" for Geoproximity routing is by looking at the IP address of the DNS resolver making the request. It then maps that resolver’s IP address to an AWS region. This mapping is not perfect and can be influenced by factors like VPNs or corporate network configurations, but it’s the primary heuristic used.
If you want to send all traffic from a specific region to a particular endpoint, you’d set a very high positive bias on that endpoint for that region and a very high negative bias on other endpoints for that same region. The maximum bias is 100, minimum is -100. A bias of 100 means Route 53 will try to send 100% of the traffic from that region to that endpoint, assuming it’s healthy.
The next step in optimizing traffic flow would be to explore latency-based routing for more granular control based on actual network latency.