Latência cloud a partir de 33 cidades: 42 regiões medidas
42 regiões cloud da Hetzner, OVHcloud, Vultr, Akamai e AWS medidas de 33 cidades: quantas são necessárias, qual atende onde e por que a rota importa.
Onde colocar um servidor quando os usuários estão em toda parte? Os provedores respondem com mapas das suas regiões. Nós medimos pelo outro lado: 33 cidades em seis continentes, até 42 regiões de 5 provedores (Hetzner, OVHcloud, Vultr, Akamai Linode e AWS), duas vezes no mesmo dia. Cada número deste artigo vem dessas medições, e os dados brutos são de uso livre.
Dados brutos: cloud-latency-2026-09.csv (CC BY 4.0). Para medir a sua própria latência até os mesmos provedores pelo navegador, use o nosso teste de latência cloud.
O que importa
- Nenhuma região atende o mundo inteiro. A melhor, Frankfurt, alcança 14 das 33 cidades em menos de 100 ms, com mediana de 130 ms.
- Uma segunda região muda tudo. Frankfurt e Singapura: 27 de 33 cidades abaixo de 100 ms, mediana de 39 ms.
- Três regiões cobrem um produto global. Frankfurt, Leste dos EUA e Singapura: 28 de 33 cidades abaixo de 100 ms, e 9 em cada 10 cidades abaixo de 114 ms.
- 7 locais, um por grande região do mundo, deixam as 33 cidades abaixo de 67 ms.
- A América Latina precisa da própria região. Das nossas cidades latino-americanas, São Paulo responde em 31 ms; o próximo melhor local, Leste dos EUA, em 110 ms.
- Nenhum provedor é o mais rápido em todo lugar. Medida pela mesma sonda nas duas rodadas, a AWS Singapura levou 239–321 ms a partir de Paris, Estocolmo e Istambul, contra 156–201 ms do provedor mais rápido em Singapura. A partir de Berlim, a AWS foi a mais rápida.
- As rotas mudam no mesmo dia. Entre as nossas duas rodadas, a Akamai Singapura ficou de 81 a 84 ms mais rápida a partir de 4 cidades europeias ao mesmo tempo, medida pelas mesmas sondas.
- A distância não explica tudo. De Joanesburgo a São Paulo levou 351 ms no melhor caso, enquanto a luz na fibra precisa de 74 ms para essa distância: os pacotes passavam pela Europa.
Onde hospedar, conforme onde estão seus usuários
Para cada grande região do mundo, a latência mediana das suas cidades até o melhor local e até o seguinte. Cada local considera o melhor dos provedores presentes ali, então a tabela diz onde hospedar, não com quem.
| Onde estão seus usuários | Melhor local (ms) | A seguir (ms) |
|---|---|---|
| Europa Amsterdã, Berlim, Istambul, Londres, Madrid, Milão, Paris, Estocolmo, Varsóvia | Frankfurt 14 | Paris / Roubaix 18 |
| América do Norte Buffalo, Los Angeles, Toronto | Montreal / Toronto 12 | Leste dos EUA 15 |
| América Latina Buenos Aires, Cidade do México, São Paulo | São Paulo 31 | Leste dos EUA 110 |
| África Fez, Joanesburgo, Lagos, Nairobi, Túnis | África do Sul 62 | Londres 104 |
| Oriente Médio e Índia Délhi, Dubai | Mumbai 26 | Singapura 75 |
| Leste e Sudeste Asiático Bangkok, Denpasar, Cidade de Ho Chi Minh, Hong Kong, Jakarta, Manila, Seul, Singapura, Taipei, Tóquio | Singapura 36 | Tóquio 64 |
| Oceania Sydney | Sydney 1 | Singapura 97 |
Quantas regiões são necessárias?
Cada cidade é atendida pelo local mais próximo do conjunto. A mediana diz o que uma cidade típica recebe; a coluna «9 em cada 10 cidades» diz até onde piora para as mais mal atendidas, que costuma ser do que os usuários reclamam. Uma ressalva: nossas 33 cidades não são ponderadas por população nem por tráfego, então o conjunto que vence aqui não é necessariamente o melhor para o seu público. A tabela por região, acima, é a que serve para decidir.
| Locais de hospedagem | Mediana (ms) | 9 em cada 10 cidades abaixo de (ms) | Cidades abaixo de 100 ms |
|---|---|---|---|
| Frankfurt | 130 | 218 | 14 / 33 |
| Frankfurt + Singapura | 39 | 154 | 27 / 33 |
| Frankfurt + Singapura + África do Sul | 38 | 97 | 30 / 33 |
| Frankfurt + Leste dos EUA + Singapura | 38 | 114 | 28 / 33 |
| Frankfurt + Montreal / Toronto + São Paulo + África do Sul + Mumbai + Singapura + Sydney | 27 | 60 | 33 / 33 |
Mesma cidade, outra rota
Comparar provedores cidade por cidade só faz sentido quando uma mesma sonda mediu todos eles, o que o Globalping não garante. A tabela mantém as cidades europeias em que isso aconteceu nas duas rodadas, com a rede da sonda abaixo da cidade. Cada célula mostra a primeira rodada e depois a segunda.
| A partir de | AWS | Hetzner | Akamai (Linode) | OVHcloud | Vultr |
|---|---|---|---|---|---|
| Paris SCALEWAY | 239 / 254 | 165 / 165 | 239 / 156 | 163 / 163 | 156 / 168 |
| Estocolmo Hollander & Jacobsen | 271 / 292 | 168 / 168 | 342 / 258 | 187 / 180 | 180 / 179 |
| Istambul 2E TELEKOMUNIKASYON | 285 / 321 | 220 / 209 | 281 / 197 | 210 / 210 | 201 / 182 |
| Berlim IONOS | 171 / 168 | 182 / 185 | 185 / 187 | 186 / 188 | 180 / 190 |
| Varsóvia OVH | 176 / 207 | 209 / 209 | 276 / 195 | – | 173 / 173 |
Os traceroutes feitos durante a segunda rodada explicam as células lentas da AWS. De Paris, o caminho passava pela NTT até Ashburn e San José, nos Estados Unidos, depois Osaka e depois Singapura: 237 ms, quase a volta ao mundo. De Estocolmo e Istambul, passava pela Tata Communications via Londres, Nova York e Tóquio. As mesmas três sondas chegavam à Vultr Singapura por Marselha e dali direto a Singapura, em 147–185 ms. A região da AWS é a mesma para todas as cidades; o que muda é o caminho que o tráfego de cada origem segue. Um traceroute anterior a partir de Berlim, também pela NTT, ia para o leste por Milão até Singapura, e Berlim teve o melhor tempo até a AWS.
As rotas também mudam. De Paris, a Akamai Singapura respondeu em 239 ms às 12h30 UTC e em 156 ms às 18h10 UTC, e um traceroute feito logo depois mostrava um caminho direto pela rede da Telstra (156 ms). A mesma queda apareceu a partir de 4 cidades europeias ao mesmo tempo, então a mudança muito provavelmente aconteceu do lado da Akamai, e não em uma das origens. Nenhuma página de status a anunciou. É por isso que um mapa de latência de provedor não resolve a questão, e que vale a pena monitorar uma rota.
A distância não explica tudo
Joanesburgo e São Paulo ficam a 7.429 km uma da outra, e cabos submarinos cruzam o Atlântico Sul diretamente (o SACS liga Angola ao Brasil). Mesmo assim, a melhor ida e volta medida foi de 351 ms, quando a luz na fibra precisaria de 74 ms. Um traceroute de Joanesburgo até a Vultr São Paulo passava pela Cidade do Cabo, Londres e Newark antes de chegar ao Brasil.
A região mais rápida a partir de cada cidade
A região mais rápida medida a partir de cada cidade, e a segunda. Valores abaixo de 2 ms significam que a sonda fica no mesmo data center que a região: não dizem nada sobre os usuários da cidade.
| A partir de | Região mais rápida | ms | Segunda (ms) |
|---|---|---|---|
| Amsterdã | OVHcloud Roubaix | 6 | Akamai (Linode) Frankfurt 7 |
| Berlim | Akamai (Linode) Frankfurt | 10 | AWS Frankfurt 11 |
| Istambul | Vultr Frankfurt | 39 | AWS Frankfurt 45 |
| Londres | Akamai (Linode) Londres | 2 | Vultr Paris 8 |
| Madrid | AWS Paris | 18 | OVHcloud Roubaix 20 |
| Milão | Vultr Frankfurt | 10 | Akamai (Linode) Frankfurt 10 |
| Paris | Akamai (Linode) Paris | 1 | Vultr Paris 1 |
| Estocolmo | Hetzner Helsinque | 7 | OVHcloud Roubaix 22 |
| Varsóvia | Vultr Frankfurt | 20 | Akamai (Linode) Frankfurt 21 |
| Buffalo | Akamai (Linode) Toronto | 12 | OVHcloud Beauharnois 12 |
| Los Angeles | AWS us-west-1 | 11 | Akamai (Linode) Fremont 12 |
| Toronto | Akamai (Linode) Toronto | 1 | OVHcloud Beauharnois 8 |
| Buenos Aires | Vultr São Paulo | 31 | AWS São Paulo 33 |
| Cidade do México | Hetzner Ashburn | 56 | Akamai (Linode) Toronto 60 |
| São Paulo | Vultr São Paulo | 1 | AWS São Paulo 2 |
| Fez | Vultr Paris | 30 | Akamai (Linode) Paris 31 |
| Joanesburgo | Vultr Joanesburgo | 1 | AWS Cape Town 35 |
| Lagos | AWS Cape Town | 56 | Vultr Joanesburgo 73 |
| Nairobi | Vultr Joanesburgo | 62 | AWS Cape Town 73 |
| Túnis | AWS Paris | 27 | Akamai (Linode) Paris 32 |
| Délhi | Akamai (Linode) Mumbai | 22 | AWS Mumbai 24 |
| Dubai | AWS UAE | 11 | AWS Mumbai 30 |
| Bangkok | Akamai (Linode) Singapura | 27 | Hetzner Singapura 32 |
| Denpasar | Akamai (Linode) Singapura | 27 | Hetzner Singapura 29 |
| Cidade de Ho Chi Minh | Akamai (Linode) Singapura | 37 | Vultr Singapura 42 |
| Hong Kong | AWS Singapore | 35 | Hetzner Singapura 35 |
| Jakarta | OVHcloud Singapura | 14 | Hetzner Singapura 14 |
| Manila | Vultr Singapura | 39 | Hetzner Singapura 39 |
| Seul | Akamai (Linode) Tóquio | 31 | AWS Tokyo 34 |
| Singapura | Akamai (Linode) Singapura | 0 | Vultr Singapura 1 |
| Taipei | Vultr Tóquio | 33 | Akamai (Linode) Tóquio 36 |
| Tóquio | Akamai (Linode) Tóquio | 1 | Vultr Tóquio 2 |
| Sydney | Akamai (Linode) Sydney | 1 | Vultr Sydney 1 |
Meça de onde estão seus usuários
Estes números foram medidos a partir de servidores. Para ver o que a sua própria conexão alcança, rode o nosso teste de latência cloud no navegador: ele cronometra requisições para 36 regiões dos mesmos provedores. Para ver o caminho, e não só o atraso, trace a rota a partir dos nossos servidores ou de 35 pontos de medição em 31 países, e compare.
Como medimos
- Sondas: uma sonda Globalping por cidade em cada medição (o Globalping pode escolher outra sonda da mesma cidade de uma medição para outra), a mesma rede que o TraceMapper usa para os seus 35 pontos de medição. Nosso ponto «Nova York» é uma sonda em Buffalo, no estado de Nova York, e aqui se chama Buffalo.
- Alvos: os pontos de teste públicos que cada provedor publica (42 regiões). A AWS bloqueia ICMP, então a AWS foi medida com conexões TCP para a porta 443 dos seus endpoints regionais do DynamoDB; todos os outros alvos, com ping ICMP.
- Amostras: 4 pacotes por par. Um SYN TCP perdido é reenviado após um segundo, então as amostras mais de 900 ms acima da mais rápida foram descartadas; o valor é a mediana do resto. Duas rodadas em 26 de setembro de 2026 (por volta das 12h30 e das 18h10 UTC); o valor de um par é a mediana das suas rodadas.
- Verificações: 2.726 medições válidas de 2.772. Cada valor foi comparado com o mínimo que a luz precisa na fibra para a distância; 2 responderam mais rápido e foram excluídas, porque a resposta veio de um equipamento mais próximo que o servidor (Los Angeles → Akamai (Linode) Paris; Los Angeles → Vultr Frankfurt). Cada traceroute citado foi conferido com o ping medido para o mesmo par. Também foram excluídas as medições feitas por uma sonda dentro da própria rede do provedor medido (39): elas medem o backbone desse provedor, não um caminho pela internet. 124 dos 1.375 pares de cidade e região variaram mais de 25 % entre as duas rodadas, sobretudo porque o Globalping escolheu outra sonda na mesma cidade; o CSV traz os dois valores.
Limites
- De servidor para servidor. As sondas Globalping ficam sobretudo em redes de hospedagem. Um usuário com conexão residencial ou móvel acrescenta a própria rede de acesso.
- Uma sonda por cidade. Outra rede da mesma cidade pode seguir outra rota. As conclusões de roteamento acima são só as que se confirmaram em todas as rodadas.
- Um retrato. As rotas mudam de uma hora para outra; duas rodadas num dia mostram a parte estável, não cada variação.
- Não é um ranking de provedores. Um provedor mais lento a partir de uma cidade costuma ser mais rápido a partir de outra; a tabela por região é a comparação justa.
Dados
As 2.772 medições, incluindo as descartadas e o motivo, estão em cloud-latency-2026-09.csv, sob a licença CC BY 4.0. Reutilize à vontade com um link para esta página: «TraceMapper, Latência cloud a partir de 33 cidades (setembro de 2026)».