Por que o tráfego do meu conteúdo da web foi roteado para o local da borda errado do CloudFront?

Breve descrição

O CloudFront direciona o tráfego com base na classe de preço da distribuição, nos bancos de dados de geolocalização associados e no suporte a EDNS0-Client-Subnet. Dependendo de uma combinação desses fatores, os visualizadores do seu site podem ser direcionados para um local da borda inesperado. Isso pode aumentar a latência geral para recuperar um objeto de um local da borda do CloudFront.

Para solucionar problemas de tráfego que direciona para um local de borda inesperado, confirme o seguinte:

• A classe de preço suporta o local da borda que você espera.
• O resolvedor de DNS suporta roteamento Anycast.
• O resolvedor de DNS suporta EDNS0-Client-Subnet.

Resolução

A classe de preço suporta o local de borda esperado

Verifique os locais da borda que estão incluídos na classe de preço da sua distribuição do CloudFront. Para incluir outros locais de borda, altere sua classe de preço.

O resolvedor de DNS suporta roteamento Anycast

Se o resolvedor de DNS suportar o roteamento Anycast, então há vários locais da borda que o resolvedor de DNS usa. Como o local de borda de um solicitante é baseado na latência ideal, você pode encontrar um local inesperado para o endereço IP do resolvedor.

Para verificar se o resolvedor de DNS oferece suporte ao Anycast, execute um dos seguintes comandos várias vezes.

Sistemas operacionais (OSs) diferentes do Windows:

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

Windows:

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

Se a saída incluir o mesmo endereço IP toda vez que você executar o comando, o resolvedor de DNS não suportará Anycast. Se a saída incluir um endereço IP diferente toda vez que você executar o comando, o resolvedor de DNS suportará Anycast.

O resolvedor de DNS suporta EDNS0-Client-Subnet

Execute um dos comandos a seguir para verificar se o resolvedor de DNS suporta EDNS0-Client-Subnet.

Sistemas operacionais diferentes do Windows:

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

Windows:

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

Observação: verifique o valor do TTL e certifique-se de executar o comando quando o TTL expirar. Caso contrário, você poderá obter uma resposta em cache do resolvedor recursivo.

Se o resolvedor de DNS não suportar EDNS0-Client-Subnet, a saída será semelhante à seguinte:

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

No exemplo anterior, 192.0.2.1 é o endereço IP do servidor DNS mais próximo que usou o Anycast. O resolvedor de DNS não suporta EDNS0-Client-Subnet.

Para garantir que o tráfego do seu site seja direcionado para o local correto, execute uma das seguintes ações:

• Mude para o resolvedor de DNS para uma resolução de DNS recursivo que está localizada geograficamente mais próxima dos clientes do seu site.
• Mude para um resolvedor de DNS que suporte EDNS0-Client-Subnet.

Se o resolvedor de DNS suportar EDNS0-Client-Subnet, a saída conterá uma sub-rede cliente truncada (/24 ou /32) para o servidor de nomes com autoridade do CloudFront:

$ dig +nocl TXT o-o.myaddr.l.google.com @8.8.8.8 +short
"192.0.2.1"
"edns0-client-subnet 198.51.100.0/24"

No exemplo anterior, 192.0.2.1 é o endereço IP do resolvedor de DNS mais próximo. O intervalo de sub-rede do cliente usado para responder à consulta de DNS é 198.51.100.0/24.

Mesmo quando seu resolvedor de DNS oferece suporte a EDNS0-Client-Subnet, o tráfego do seu site ainda pode ser roteado incorretamente. Para resolver esse problema, associe um banco de dados público de geolocalização ao intervalo de sub-rede do cliente que envia a consulta ao resolvedor de DNS. Se o resolvedor de DNS encaminhar a versão truncada dos endereços IP do cliente para os servidores de nomes do CloudFront, o CloudFront verificará um banco de dados baseado em vários bancos de dados de geolocalização públicos.

Você deve mapear corretamente os endereços IP no banco de dados de geolocalização para que as solicitações sejam roteadas corretamente.

Se o resolvedor de DNS oferecer suporte a EDNS0-Client-Subnet, execute o seguinte comando de pesquisa de DNS para determinar o local de borda para o qual o tráfego é roteado:

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

Em seguida, execute uma pesquisa inversa de DNS nos endereços IP que o comando anterior retorna:

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

No exemplo anterior, o tráfego é direcionado para o local da borda de Manchester.

Dica: para um teste adicional, você pode usar um resolvedor de DNS público que suporte EDNS0-Client-Subnet, como 8.8.8.8, 8.8.4.4 ou 1.1.1.1. Envie consultas com endereços IP de local da borda para o resolvedor de DNS público. Em seguida, verifique os resultados das consultas de DNS para ver se o CloudFront tem as informações corretas sobre EDNS0-Client-Subnet.