Se você não é representante da conta da AWS que possui a distribuição do CloudFront - e o fraseado usado na pergunta faz parecer que você não é - então o ponto de contato apropriado é o site onde você está estão tendo um desempenho ruim.
Seria então a sua responsabilidade de abrir um incidente de suporte com o suporte da AWS, se considerarem apropriado, uma vez que são clientes do CloudFront.
O CloudFront foi projetado para rotear sua solicitação para o ponto de presença mais adequado do CloudFront (onde "ideal" geralmente, mas nem sempre significa geograficamente próximo) na camada de preços selecionada pelo proprietário da distribuição (os proprietários podem optar por não pagar por arestas mais caras) , onde os custos da Amazon são maiores, caso em que as solicitações desse site evitarão essas bordas ou, pelo menos, evitarão preços premium, mesmo que o CloudFront possa, a seu critério, usar um local de custo mais alto, mas faturar na menor taxa). p>
A borda ideal para a localização de um determinado baixador mudará com o tempo, devido a vários fatores, incluindo latência, congestionamento, tamanhos de caminho de salto e AS, largura de banda de link e vários outros fatores ... que não são públicos informações, mas são levadas em conta pelos algoritmos de roteamento do CloudFront que determinam qual resposta de DNS você recebe quando se conecta a um site com o CloudFront. A resposta do DNS varia de acordo com o endereço IP do cliente solicitante.
De um único endereço IP de origem no Sul de Ohio (EUA), vejo meu site de teste do CloudFront percorrer um ponto de presença que muda entre o sul Bend (IN, EUA), Chicago (IL, EUA) e Ashburn (VA, EUA) em uma base bastante regular - sem o endereço IP real estou solicitando a página de até mesmo mudando. De uma configuração semelhante a menos de 8 km de distância, mas com um endereço IP de origem estática diferente usando um ISP diferente, recebo respostas semelhantes, variadas, mas frequentemente diferentes.
Isso pode ser facilmente explicado pelos algoritmos do CloudFront tentando selecionar a borda mais apropriada, com base em fatores que não são óbvios do lado de fora olhando para dentro.
Por tudo o que você pode saber, seu comportamento lento nas conexões com o CloudFront de ontem pode ter sido detectado e acionou o algoritmo de seleção para escolher uma estratégia diferente, fazendo com que o problema de desempenho "se conserte". Também é possível que a borda de Madri estivesse sendo usada como uma escolha abaixo do ideal, devido a problemas de disponibilidade em uma melhor escolha de local.
Também pode ter havido um problema entre o CloudFront e o servidor de origem. Os cabeçalhos de resposta do CloudFront teriam dado a você um pouco mais de informações ... Se X-Cache: Hit from Cloudfront estiver presente, você está sendo servido do cache de borda, e o Age: dirá quanto tempo o objeto foi armazenado em cache no A beira. Se X-Cache: Miss from Cloudfront , seu download não foi armazenado em cache na borda, e o arquivo que você está recebendo atualmente está sendo buscado no servidor de origem e, ao mesmo tempo, está sendo preparado para o cache e sendo transmitido de volta para você. Permitir que o download seja totalmente concluído e, em seguida, fazer download novamente com uma solicitação idêntica deve fornecer a cópia em cache, supondo que sua próxima solicitação atinja a mesma borda e a diferença de velocidade, se houver, seja aproximadamente indicativa da velocidade de conexão para o servidor de origem . CloudFront é um CDN pull-through; objetos não são replicados para as bordas, eles são armazenados apenas em locais onde foram solicitados, após a solicitação inicial.
Como cliente do CloudFront, nunca precisei relatar downloads lentos. Isso não significa que é perfeito, mas o serviço parece ser muito solidamente projetado para desempenho e resiliência.