Cloud-Latenz aus 33 Städten: 42 Regionen gemessen
42 Cloud-Regionen von Hetzner, OVHcloud, Vultr, Akamai und AWS aus 33 Städten gemessen: wie viele man braucht, welche wo dient, warum die Route zählt.
Wo soll ein Server stehen, wenn seine Nutzer überall sind? Anbieter antworten mit Karten ihrer Regionen. Wir haben vom anderen Ende gemessen: aus 33 Städten auf sechs Kontinenten zu 42 Regionen von 5 Anbietern (Hetzner, OVHcloud, Vultr, Akamai Linode und AWS), zweimal am selben Tag. Jede Zahl in diesem Artikel stammt aus diesen Messungen, und die Rohdaten dürfen frei weiterverwendet werden.
Rohdaten: cloud-latency-2026-09.csv (CC BY 4.0). Um Ihre eigene Latenz zu denselben Anbietern im Browser zu messen, nutzen Sie unseren Cloud-Latenztest.
Die wichtigsten Ergebnisse
- Keine einzelne Region bedient die ganze Welt. Die beste, Frankfurt, erreicht 14 der 33 Städte in unter 100 ms, im Median in 130 ms.
- Eine zweite Region ändert alles. Frankfurt und Singapur: 27 von 33 Städten unter 100 ms, Median 39 ms.
- Drei Regionen decken ein globales Produkt ab. Frankfurt, US-Ostküste und Singapur: 28 von 33 Städten unter 100 ms, und 9 von 10 Städten unter 114 ms.
- 7 Standorte, einer pro Weltregion, bringen alle 33 Städte unter 67 ms.
- Lateinamerika braucht eine eigene Region. Aus unseren lateinamerikanischen Städten antwortet São Paulo in 31 ms, der nächstbeste Standort, US-Ostküste, in 110 ms.
- Kein Anbieter ist überall der schnellste. Von derselben Sonde in beiden Durchläufen gemessen, brauchte AWS Singapur aus Paris, Stockholm und Istanbul 239–321 ms, gegenüber 156–201 ms beim schnellsten Anbieter in Singapur. Aus Berlin war AWS der schnellste.
- Routen ändern sich im Laufe eines Tages. Zwischen unseren beiden Durchläufen wurde Akamai Singapur aus 4 europäischen Städten gleichzeitig um 81 bis 84 ms schneller, gemessen von denselben Sonden.
- Die Entfernung erklärt nicht alles. Johannesburg nach São Paulo dauerte bestenfalls 351 ms, während Licht in der Glasfaser für diese Strecke 74 ms braucht: Die Pakete liefen über Europa.
Wo hosten, je nachdem, wo Ihre Nutzer sind
Für jede Weltregion die mediane Latenz aus ihren Städten zum besten Standort und zum zweitbesten. Jeder Standort nimmt den besten der dort vertretenen Anbieter: Die Tabelle beantwortet, wo gehostet werden sollte, nicht bei wem.
| Wo Ihre Nutzer sind | Bester Standort (ms) | Danach (ms) |
|---|---|---|
| Europa Amsterdam, Berlin, Istanbul, London, Madrid, Mailand, Paris, Stockholm, Warschau | Frankfurt 14 | Paris / Roubaix 18 |
| Nordamerika Buffalo, Los Angeles, Toronto | Montreal / Toronto 12 | US-Ostküste 15 |
| Lateinamerika Buenos Aires, Mexiko-Stadt, São Paulo | São Paulo 31 | US-Ostküste 110 |
| Afrika Fès, Johannesburg, Lagos, Nairobi, Tunis | Südafrika 62 | London 104 |
| Naher Osten & Indien Delhi, Dubai | Mumbai 26 | Singapur 75 |
| Ost- und Südostasien Bangkok, Denpasar, Ho-Chi-Minh-Stadt, Hong Kong, Jakarta, Manila, Seoul, Singapur, Taipei, Tokio | Singapur 36 | Tokio 64 |
| Ozeanien Sydney | Sydney 1 | Singapur 97 |
Wie viele Regionen braucht man?
Jede Stadt wird vom nächstgelegenen Standort der Auswahl bedient. Der Median zeigt, was eine typische Stadt bekommt; die Spalte „9 von 10 Städten“ zeigt, wie schlecht es für die am schlechtesten versorgten wird, und darüber beschweren sich Nutzer meist. Ein Vorbehalt: Unsere 33 Städte sind weder nach Bevölkerung noch nach Verkehr gewichtet, die Auswahl, die hier gewinnt, ist also nicht automatisch die beste für Ihr Publikum. Für eine Entscheidung ist die Tabelle nach Region weiter oben maßgeblich.
| Hosting-Standorte | Median (ms) | 9 von 10 Städten unter (ms) | Städte unter 100 ms |
|---|---|---|---|
| Frankfurt | 130 | 218 | 14 / 33 |
| Frankfurt + Singapur | 39 | 154 | 27 / 33 |
| Frankfurt + Singapur + Südafrika | 38 | 97 | 30 / 33 |
| Frankfurt + US-Ostküste + Singapur | 38 | 114 | 28 / 33 |
| Frankfurt + Montreal / Toronto + São Paulo + Südafrika + Mumbai + Singapur + Sydney | 27 | 60 | 33 / 33 |
Gleiche Stadt, andere Route
Anbieter Stadt für Stadt zu vergleichen, ist nur sinnvoll, wenn eine Sonde alle gemessen hat, was Globalping nicht garantiert. Die Tabelle behält die europäischen Städte, bei denen das in beiden Durchläufen zutraf, mit dem Netz der Sonde unter der Stadt. Jede Zelle zeigt den ersten, dann den zweiten Durchlauf.
| Von | AWS | Hetzner | Akamai (Linode) | OVHcloud | Vultr |
|---|---|---|---|---|---|
| Paris SCALEWAY | 239 / 254 | 165 / 165 | 239 / 156 | 163 / 163 | 156 / 168 |
| Stockholm Hollander & Jacobsen | 271 / 292 | 168 / 168 | 342 / 258 | 187 / 180 | 180 / 179 |
| Istanbul 2E TELEKOMUNIKASYON | 285 / 321 | 220 / 209 | 281 / 197 | 210 / 210 | 201 / 182 |
| Berlin IONOS | 171 / 168 | 182 / 185 | 185 / 187 | 186 / 188 | 180 / 190 |
| Warschau OVH | 176 / 207 | 209 / 209 | 276 / 195 | – | 173 / 173 |
Traceroutes aus dem zweiten Durchlauf erklären die langsamen AWS-Zellen. Aus Paris lief der Pfad über NTT nach Ashburn und San José in den USA, dann nach Osaka und Singapur: 237 ms, fast einmal um die Welt. Aus Stockholm und Istanbul lief er über Tata Communications via London, New York und Tokio. Dieselben drei Sonden erreichten Vultr Singapur über Marseille und dann direkt Singapur, in 147–185 ms. Die AWS-Region ist für alle Städte dieselbe; anders ist der Weg, den der Verkehr jedes Ausgangspunkts nimmt. Ein früherer Traceroute aus Berlin, ebenfalls über NTT, lief nach Osten über Mailand nach Singapur, und Berlin erzielte die schnellste AWS-Zeit.
Auch Routen verschieben sich. Aus Paris antwortete Akamai Singapur um 12:30 Uhr UTC in 239 ms und um 18:10 Uhr UTC in 156 ms, und ein kurz danach aufgenommener Traceroute zeigte einen direkten Pfad durch das Netz von Telstra (156 ms). Derselbe Rückgang trat in 4 europäischen Städten gleichzeitig auf, die Änderung geschah also höchstwahrscheinlich auf der Seite von Akamai und nicht bei einem einzelnen Ausgangspunkt. Keine Statusseite hat sie angekündigt. Deshalb klärt die Latenzkarte eines Anbieters die Frage nicht, und deshalb lohnt es sich, eine Route zu überwachen.
Die Entfernung erklärt nicht alles
Johannesburg und São Paulo liegen 7.429 km auseinander, und Seekabel queren den Südatlantik direkt (SACS verbindet Angola mit Brasilien). Die beste gemessene Umlaufzeit lag trotzdem bei 351 ms, wo Licht in der Glasfaser 74 ms bräuchte. Ein Traceroute von Johannesburg zu Vultr São Paulo lief über Kapstadt, London und Newark, bevor er Brasilien erreichte.
Die schnellste Region aus jeder Stadt
Die schnellste gemessene Region aus jeder Stadt und die zweitschnellste. Werte unter 2 ms bedeuten, dass die Messsonde im selben Rechenzentrum steht wie die Region: Über die Nutzer der Stadt sagen sie nichts.
| Von | Schnellste Region | ms | Zweitschnellste (ms) |
|---|---|---|---|
| Amsterdam | OVHcloud Roubaix | 6 | Akamai (Linode) Frankfurt 7 |
| Berlin | Akamai (Linode) Frankfurt | 10 | AWS Frankfurt 11 |
| Istanbul | Vultr Frankfurt | 39 | AWS Frankfurt 45 |
| London | Akamai (Linode) London | 2 | Vultr Paris 8 |
| Madrid | AWS Paris | 18 | OVHcloud Roubaix 20 |
| Mailand | Vultr Frankfurt | 10 | Akamai (Linode) Frankfurt 10 |
| Paris | Akamai (Linode) Paris | 1 | Vultr Paris 1 |
| Stockholm | Hetzner Helsinki | 7 | OVHcloud Roubaix 22 |
| Warschau | 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 |
| Mexiko-Stadt | Hetzner Ashburn | 56 | Akamai (Linode) Toronto 60 |
| São Paulo | Vultr São Paulo | 1 | AWS São Paulo 2 |
| Fès | Vultr Paris | 30 | Akamai (Linode) Paris 31 |
| Johannesburg | Vultr Johannesburg | 1 | AWS Cape Town 35 |
| Lagos | AWS Cape Town | 56 | Vultr Johannesburg 73 |
| Nairobi | Vultr Johannesburg | 62 | AWS Cape Town 73 |
| Tunis | AWS Paris | 27 | Akamai (Linode) Paris 32 |
| Delhi | Akamai (Linode) Mumbai | 22 | AWS Mumbai 24 |
| Dubai | AWS UAE | 11 | AWS Mumbai 30 |
| Bangkok | Akamai (Linode) Singapur | 27 | Hetzner Singapur 32 |
| Denpasar | Akamai (Linode) Singapur | 27 | Hetzner Singapur 29 |
| Ho-Chi-Minh-Stadt | 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 |
| Seoul | Akamai (Linode) Tokio | 31 | AWS Tokyo 34 |
| Singapur | Akamai (Linode) Singapur | 0 | Vultr Singapur 1 |
| Taipei | Vultr Tokio | 33 | Akamai (Linode) Tokio 36 |
| Tokio | Akamai (Linode) Tokio | 1 | Vultr Tokio 2 |
| Sydney | Akamai (Linode) Sydney | 1 | Vultr Sydney 1 |
Messen Sie dort, wo Ihre Nutzer sind
Diese Zahlen wurden von Servern aus gemessen. Um zu sehen, was Ihre eigene Verbindung erreicht, starten Sie unseren Cloud-Latenztest im Browser: Er misst Anfragen zu 36 Regionen derselben Anbieter. Um den Pfad zu sehen und nicht nur die Verzögerung, verfolgen Sie die Route von unseren Servern oder von 35 Standorten in 31 Ländern und vergleichen Sie.
So haben wir gemessen
- Sonden: eine Globalping-Sonde pro Stadt und Messung (Globalping kann von Messung zu Messung eine andere Sonde in derselben Stadt wählen), dasselbe Netz, das TraceMapper für seine 35 Messstandorte nutzt. Unser Standort „New York“ ist eine Sonde in Buffalo im Bundesstaat New York und heißt hier Buffalo.
- Ziele: die öffentlichen Testendpunkte, die jeder Anbieter veröffentlicht (42 Regionen). AWS verwirft ICMP, daher wurde AWS mit TCP-Verbindungen zu Port 443 seiner regionalen DynamoDB-Endpunkte gemessen, alle anderen Ziele per ICMP-Ping.
- Stichproben: 4 Pakete pro Paar. Ein verlorenes TCP-SYN wird nach einer Sekunde erneut gesendet, daher wurden Stichproben verworfen, die mehr als 900 ms über der schnellsten lagen; der Wert ist der Median der übrigen. Zwei Durchläufe am 26. September 2026 (gegen 12:30 und 18:10 Uhr UTC); der Wert eines Paares ist der Median seiner Durchläufe.
- Kontrollen: 2.726 gültige Messungen von 2.772. Jeder Wert wurde mit dem Minimum verglichen, das Licht in der Glasfaser für die Strecke braucht; 2 antworteten schneller und wurden ausgeschlossen, weil die Antwort von einem Gerät kam, das näher lag als der Server (Los Angeles → Akamai (Linode) Paris; Los Angeles → Vultr Frankfurt). Jeder zitierte Traceroute wurde mit dem für dasselbe Paar gemessenen Ping abgeglichen. Ebenfalls ausgeschlossen wurden Messungen einer Sonde im eigenen Netz des gemessenen Anbieters (39): Sie messen dessen Backbone, keinen Pfad durchs Internet. 124 der 1.375 Paare aus Stadt und Region schwankten zwischen den beiden Durchläufen um mehr als 25 %, meist weil Globalping in derselben Stadt eine andere Sonde wählte; die CSV enthält beide Werte.
Grenzen
- Von Server zu Server. Globalping-Sonden stehen überwiegend in Hosting-Netzen. Nutzer mit Heim- oder Mobilfunkanschluss fügen ihr eigenes Zugangsnetz hinzu.
- Eine Sonde pro Stadt. Ein anderes Netz in derselben Stadt kann eine andere Route nehmen. Die Routing-Ergebnisse oben sind nur jene, die in jedem Durchlauf galten.
- Eine Momentaufnahme. Routen ändern sich von Stunde zu Stunde; zwei Durchläufe an einem Tag zeigen den stabilen Teil, nicht jede Schwankung.
- Kein Anbieter-Ranking. Ein Anbieter, der aus einer Stadt langsamer ist, ist aus einer anderen oft schneller; die Tabelle nach Region ist der faire Vergleich.
Daten
Alle 2.772 Messungen, auch die verworfenen samt Grund, stehen in cloud-latency-2026-09.csv unter der Lizenz CC BY 4.0. Verwenden Sie sie frei mit einem Link auf diese Seite: „TraceMapper, Cloud-Latenz aus 33 Städten (September 2026)“.