Why did the traffic for my web content get routed to the wrong CloudFront edge location?

Short description

CloudFront routes traffic based on the distribution's price class, associated geolocation databases, and EDNS0-Client-Subnet support. Based on a combination of these factors, your website's viewers might be routed to an unexpected edge location. This can increase the overall latency to retrieve an object from a CloudFront edge location.

To troubleshoot traffic that routs to an unexpected edge location, confirm the following:

• The price class supports the edge location that you expect.
• The DNS resolver supports Anycast routing.
• The DNS resolver supports EDNS0-Client-Subnet.

Resolution

The price class supports the expected edge location

Check the edge locations that are included in the price class of your CloudFront distribution. To include other edge locations, change your price class.

The DNS resolver supports Anycast routing

If the DNS resolver supports Anycast routing, then there are multiple edge locations that the DNS resolver uses. Because a requester's edge location is based on optimal latency, you might experience an unexpected location for the resolver's IP address.

To check whether the DNS resolver supports Anycast, run one of the following commands multiple times.

Operating systems (OSs) other than Windows:

dig +nocl TXT o-o.myaddr.l.google.com

Windows:

nslookup -type=txt o-o.myaddr.l.google.com

If the output includes the same IP address each time you run the command, then the DNS resolver doesn't support Anycast. If the output includes a different IP address each time you run the command, then the DNS resolver supports Anycast.

The DNS resolver supports EDNS0-Client-Subnet

Run one of the following commands to check whether the DNS resolver supports EDNS0-Client-Subnet.

OSs other than Windows:

dig +nocl TXT o-o.myaddr.l.google.com +short

Windows:

nslookup -type=txt o-o.myaddr.l.google.com

Note: Check the TTL value, and be sure to run the command after the TTL expires. Otherwise, you might get a cached response from the recursive resolver.

If the DNS resolver doesn't support EDNS0-Client-Subnet, then the output is similar to the following:

"192.0.2.1"

In the preceding example, 192.0.2.1 is the IP address of the closest DNS server that used Anycast.

If the DNS resolver doesn't support EDNS0-Client-Subnet, then to route your website traffic to the correct location, take one of the following actions:

• Change the DNS resolver to a recursive DNS resolver that's located geographically closer to your website's clients.
• Change to a DNS resolver that supports EDNS0-Client-Subnet.

To check whether the DNS resolver supports EDNS0-Client-Subnet, run the dig command with @8.8.8.8 to specify a public DNS resolver that's known to support EDNS0-Client-Subnet:

dig +nocl TXT o-o.myaddr.l.google.com @8.8.8.8 +short

If the DNS resolver supports EDNS0-Client-Subnet, then the output contains a truncated client subnet, either /24 or /32, to the CloudFront authoritative name server:

"192.0.2.1"
"edns0-client-subnet 198.51.100.0/24"

In the preceding example, 192.0.2.1 is the closest DNS resolver IP address. The client-subnet range that's used to respond to DNS query is 198.51.100.0/24.

Even when your DNS resolver supports EDNS0-Client-Subnet, your website traffic might still be incorrectly routed. To resolve this issue, associate the MaxMind public geolocation database with the client-subnet range that sends the query to the DNS resolver. If the DNS resolver forwards the truncated version of the client IP addresses to CloudFront name servers, then CloudFront checks the MaxMind database. For more information see the MaxMind website.

You must correctly map the IP addresses in the geolocation database so that requests are routed correctly.

If the DNS resolver supports EDNS0-Client-Subnet, then run the following DNS lookup command to determine the edge location that traffic is routed to:

dig dftex7example.cloudfront.net. +short
13.224.77.109
13.224.77.62
13.224.77.65
13.224.77.75

Then, run a reverse DNS lookup on the IP addresses that the preceding command returns:

dig -x 13.224.77.62 +short
server-13-224-77-62.man50.r.cloudfront.net.

In the preceding example, the traffic is routed to the Manchester edge location.

Tip: For an additional test, you can use a public DNS resolver that supports EDNS0-Client-Subnet, such as 8.8.8.8, 8.8.4.4, or 1.1.1.1. Send queries with edge location IP addresses to the public DNS resolver. Then, check the results of the DNS queries to see whether CloudFront has the correct information about your EDNS0-Client-Subnet.