Latencia cloud desde 33 ciudades: 42 regiones medidas
42 regiones cloud de Hetzner, OVHcloud, Vultr, Akamai y AWS medidas desde 33 ciudades: cuántas hacen falta, cuál sirve dónde y por qué importa la ruta.
¿Dónde poner un servidor cuando sus usuarios están en todas partes? Los proveedores responden con mapas de sus regiones. Nosotros medimos desde el otro extremo: 33 ciudades en seis continentes, hacia 42 regiones de 5 proveedores (Hetzner, OVHcloud, Vultr, Akamai Linode y AWS), dos veces el mismo día. Cada cifra de este artículo sale de esas mediciones, y los datos brutos son de libre reutilización.
Datos brutos: cloud-latency-2026-09.csv (CC BY 4.0). Para medir tu propia latencia hacia los mismos proveedores desde tu navegador, usa nuestro test de latencia cloud.
Lo más importante
- Ninguna región sirve al mundo entero. La mejor, Fráncfort, llega a 14 de las 33 ciudades en menos de 100 ms, con una mediana de 130 ms.
- Una segunda región lo cambia todo. Fráncfort y Singapur: 27 de 33 ciudades por debajo de 100 ms, mediana de 39 ms.
- Tres regiones cubren un producto global. Fráncfort, Este de EE. UU. y Singapur: 28 de 33 ciudades por debajo de 100 ms, y 9 de cada 10 ciudades por debajo de 114 ms.
- 7 ubicaciones, una por gran región del mundo, dejan las 33 ciudades por debajo de 67 ms.
- América Latina necesita su propia región. Desde nuestras ciudades latinoamericanas, São Paulo responde en 31 ms; la siguiente mejor ubicación, Este de EE. UU., en 110 ms.
- Ningún proveedor es el más rápido en todas partes. Medido por la misma sonda en las dos rondas, AWS Singapur tardó 239–321 ms desde París, Estocolmo y Estambul, frente a 156–201 ms del proveedor más rápido en Singapur. Desde Berlín, AWS fue el más rápido.
- Las rutas cambian en un mismo día. Entre nuestras dos rondas, Akamai Singapur pasó a ser entre 81 y 84 ms más rápido desde 4 ciudades europeas a la vez, medido por las mismas sondas.
- La distancia no lo explica todo. De Johannesburgo a São Paulo se tardó 351 ms en el mejor caso, cuando la luz en la fibra necesita 74 ms para esa distancia: los paquetes pasaban por Europa.
Dónde alojar, según dónde estén tus usuarios
Para cada gran región del mundo, la latencia mediana desde sus ciudades hacia la mejor ubicación y hacia la siguiente. Cada ubicación toma el mejor de los proveedores presentes, así que la tabla dice dónde alojar, no con quién.
| Dónde están tus usuarios | Mejor ubicación (ms) | Siguiente (ms) |
|---|---|---|
| Europa Ámsterdam, Berlín, Estambul, Londres, Madrid, Milán, París, Estocolmo, Varsovia | Fráncfort 14 | París / Roubaix 18 |
| Norteamérica Buffalo, Los Angeles, Toronto | Montreal / Toronto 12 | Este de EE. UU. 15 |
| América Latina Buenos Aires, Ciudad de México, São Paulo | São Paulo 31 | Este de EE. UU. 110 |
| África Fez, Johannesburgo, Lagos, Nairobi, Túnez | Sudáfrica 62 | Londres 104 |
| Oriente Medio e India Delhi, Dubái | Bombay 26 | Singapur 75 |
| Asia oriental y sudoriental Bangkok, Denpasar, Ciudad Ho Chi Minh, Hong Kong, Jakarta, Manila, Seúl, Singapur, Taipéi, Tokio | Singapur 36 | Tokio 64 |
| Oceanía Sídney | Sídney 1 | Singapur 97 |
¿Cuántas regiones hacen falta?
Cada ciudad se sirve desde la ubicación más cercana del conjunto. La mediana dice lo que obtiene una ciudad típica; la columna «9 de cada 10 ciudades» dice hasta dónde empeora para las peor servidas, que suele ser de lo que se quejan los usuarios. Una advertencia: nuestras 33 ciudades no están ponderadas por población ni por tráfico, así que el conjunto que gana aquí no es por fuerza el mejor para tu público. La tabla por región de arriba es la que sirve para decidir.
| Ubicaciones de alojamiento | Mediana (ms) | 9 de cada 10 ciudades por debajo de (ms) | Ciudades por debajo de 100 ms |
|---|---|---|---|
| Fráncfort | 130 | 218 | 14 / 33 |
| Fráncfort + Singapur | 39 | 154 | 27 / 33 |
| Fráncfort + Singapur + Sudáfrica | 38 | 97 | 30 / 33 |
| Fráncfort + Este de EE. UU. + Singapur | 38 | 114 | 28 / 33 |
| Fráncfort + Montreal / Toronto + São Paulo + Sudáfrica + Bombay + Singapur + Sídney | 27 | 60 | 33 / 33 |
Misma ciudad, otra ruta
Comparar proveedores ciudad por ciudad solo tiene sentido si una misma sonda los midió a todos, algo que Globalping no garantiza. La tabla conserva las ciudades europeas donde fue así en las dos rondas, con la red de la sonda bajo la ciudad. Cada celda da la primera ronda y luego la segunda.
| Desde | AWS | Hetzner | Akamai (Linode) | OVHcloud | Vultr |
|---|---|---|---|---|---|
| París SCALEWAY | 239 / 254 | 165 / 165 | 239 / 156 | 163 / 163 | 156 / 168 |
| Estocolmo Hollander & Jacobsen | 271 / 292 | 168 / 168 | 342 / 258 | 187 / 180 | 180 / 179 |
| Estambul 2E TELEKOMUNIKASYON | 285 / 321 | 220 / 209 | 281 / 197 | 210 / 210 | 201 / 182 |
| Berlín IONOS | 171 / 168 | 182 / 185 | 185 / 187 | 186 / 188 | 180 / 190 |
| Varsovia OVH | 176 / 207 | 209 / 209 | 276 / 195 | – | 173 / 173 |
Los traceroutes tomados durante la segunda ronda explican las celdas lentas de AWS. Desde París, el camino pasaba por NTT hasta Ashburn y San José, en Estados Unidos, luego Osaka y luego Singapur: 237 ms, casi la vuelta al mundo. Desde Estocolmo y Estambul pasaba por Tata Communications vía Londres, Nueva York y Tokio. Las mismas tres sondas llegaban a Vultr Singapur por Marsella y de ahí directamente a Singapur, en 147–185 ms. La región de AWS es la misma para todas las ciudades; lo que cambia es el camino que toma el tráfico de cada origen. Un traceroute anterior desde Berlín, también por NTT, iba hacia el este por Milán hasta Singapur, y Berlín obtuvo el mejor tiempo hacia AWS.
Las rutas también cambian. Desde París, Akamai Singapur respondió en 239 ms a las 12:30 UTC y en 156 ms a las 18:10 UTC, y un traceroute tomado poco después mostraba un camino directo por la red de Telstra (156 ms). La misma bajada apareció desde 4 ciudades europeas a la vez, así que el cambio se produjo muy probablemente del lado de Akamai y no en uno de los orígenes. Ninguna página de estado lo anunció. Por eso un mapa de latencia de un proveedor no zanja la cuestión, y por eso vale la pena vigilar una ruta.
La distancia no lo explica todo
Johannesburgo y São Paulo están a 7.429 km, y hay cables submarinos que cruzan directamente el Atlántico Sur (SACS une Angola con Brasil). Aun así, el mejor viaje de ida y vuelta medido fue de 351 ms, cuando la luz en la fibra necesitaría 74 ms. Un traceroute de Johannesburgo a Vultr São Paulo pasaba por Ciudad del Cabo, Londres y Newark antes de llegar a Brasil.
La región más rápida desde cada ciudad
La región más rápida medida desde cada ciudad, y la segunda. Un valor por debajo de 2 ms significa que la sonda está en el mismo centro de datos que la región: no dice nada de los usuarios de esa ciudad.
| Desde | Región más rápida | ms | Segunda (ms) |
|---|---|---|---|
| Ámsterdam | OVHcloud Roubaix | 6 | Akamai (Linode) Fráncfort 7 |
| Berlín | Akamai (Linode) Fráncfort | 10 | AWS Frankfurt 11 |
| Estambul | Vultr Fráncfort | 39 | AWS Frankfurt 45 |
| Londres | Akamai (Linode) Londres | 2 | Vultr París 8 |
| Madrid | AWS Paris | 18 | OVHcloud Roubaix 20 |
| Milán | Vultr Fráncfort | 10 | Akamai (Linode) Fráncfort 10 |
| París | Akamai (Linode) París | 1 | Vultr París 1 |
| Estocolmo | Hetzner Helsinki | 7 | OVHcloud Roubaix 22 |
| Varsovia | Vultr Fráncfort | 20 | Akamai (Linode) Fráncfort 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 |
| Ciudad de México | Hetzner Ashburn | 56 | Akamai (Linode) Toronto 60 |
| São Paulo | Vultr São Paulo | 1 | AWS São Paulo 2 |
| Fez | Vultr París | 30 | Akamai (Linode) París 31 |
| Johannesburgo | Vultr Johannesburgo | 1 | AWS Cape Town 35 |
| Lagos | AWS Cape Town | 56 | Vultr Johannesburgo 73 |
| Nairobi | Vultr Johannesburgo | 62 | AWS Cape Town 73 |
| Túnez | AWS Paris | 27 | Akamai (Linode) París 32 |
| Delhi | Akamai (Linode) Bombay | 22 | AWS Mumbai 24 |
| Dubái | AWS UAE | 11 | AWS Mumbai 30 |
| Bangkok | Akamai (Linode) Singapur | 27 | Hetzner Singapur 32 |
| Denpasar | Akamai (Linode) Singapur | 27 | Hetzner Singapur 29 |
| Ciudad Ho Chi Minh | Akamai (Linode) Singapur | 37 | Vultr Singapur 42 |
| Hong Kong | AWS Singapore | 35 | Hetzner Singapur 35 |
| Jakarta | OVHcloud Singapur | 14 | Hetzner Singapur 14 |
| Manila | Vultr Singapur | 39 | Hetzner Singapur 39 |
| Seúl | Akamai (Linode) Tokio | 31 | AWS Tokyo 34 |
| Singapur | Akamai (Linode) Singapur | 0 | Vultr Singapur 1 |
| Taipéi | Vultr Tokio | 33 | Akamai (Linode) Tokio 36 |
| Tokio | Akamai (Linode) Tokio | 1 | Vultr Tokio 2 |
| Sídney | Akamai (Linode) Sídney | 1 | Vultr Sídney 1 |
Mídelo desde donde están tus usuarios
Estas cifras se midieron desde servidores. Para ver lo que obtiene tu propia conexión, ejecuta nuestro test de latencia cloud en tu navegador: cronometra solicitudes hacia 36 regiones de los mismos proveedores. Para ver el camino, y no solo el retraso, traza la ruta desde nuestros servidores o desde 35 puntos de medición en 31 países, y compara.
Cómo medimos
- Sondas: una sonda de Globalping por ciudad en cada medición (Globalping puede elegir otra sonda de la misma ciudad de una medición a otra), la misma red que usa TraceMapper para sus 35 puntos de medición. Nuestro punto «Nueva York» es una sonda en Buffalo, estado de Nueva York, y aquí se llama Buffalo.
- Objetivos: los puntos de prueba públicos que publica cada proveedor (42 regiones). AWS bloquea el ICMP, así que AWS se midió con conexiones TCP al puerto 443 de sus puntos de acceso regionales de DynamoDB; todos los demás objetivos, con ping ICMP.
- Muestras: 4 paquetes por par. Un SYN TCP perdido se reenvía al cabo de un segundo, así que se descartaron las muestras más de 900 ms por encima de la más rápida; el valor es la mediana del resto. Dos rondas el 26 de septiembre de 2026 (hacia las 12:30 y las 18:10 UTC); el valor de un par es la mediana de sus rondas.
- Comprobaciones: 2.726 mediciones válidas de 2.772. Cada valor se comparó con el mínimo que necesita la luz en la fibra para esa distancia; 2 respondieron más rápido y se excluyeron, porque la respuesta venía de un equipo más cercano que el servidor (Los Angeles → Akamai (Linode) Paris; Los Angeles → Vultr Frankfurt). Cada traceroute citado se contrastó con el ping medido para el mismo par. También se excluyeron las mediciones tomadas por una sonda situada dentro de la red del propio proveedor medido (39): miden la red troncal de ese proveedor, no un camino por internet. 124 de los 1.375 pares de ciudad y región variaron más de un 25 % entre las dos rondas, sobre todo porque Globalping eligió otra sonda en la misma ciudad; el CSV contiene los dos valores.
Límites
- De servidor a servidor. Las sondas de Globalping están sobre todo en redes de alojamiento. Un usuario con conexión doméstica o móvil añade su propia red de acceso.
- Una sonda por ciudad. Otra red de la misma ciudad puede tomar otra ruta. Las conclusiones de enrutamiento de arriba son solo las que se cumplieron en todas las rondas.
- Una instantánea. Las rutas cambian de una hora a otra; dos rondas en un día muestran la parte estable, no cada variación.
- No es una clasificación de proveedores. Un proveedor más lento desde una ciudad suele ser más rápido desde otra; la tabla por región es la comparación justa.
Datos
Las 2.772 mediciones, incluidas las descartadas y su motivo, están en cloud-latency-2026-09.csv, bajo licencia CC BY 4.0. Reutilízalas libremente con un enlace a esta página: «TraceMapper, Latencia cloud desde 33 ciudades (septiembre de 2026)».