Die Latenzmathematik: Was die Physik vorgibt
Licht im Vakuum bewegt sich mit 299.792 km/s. In Glasfaser läuft Licht mit etwa 2/3 davon – rund 200.000 km/s, also etwa 5 ms pro 1.000 km einseitig. Die Round-Trip-Time (RTT) ist der doppelte Wert: ~10 ms pro 1.000 km Glasfaserstrecke. Reale Glasfaserpfade sind meist 1,3–2× länger als die Großkreisdistanz – planen Sie zusätzliche Latenz für Routing-Realitäten ein.
Licht verlangsamt sich in Glas durch den Brechungsindex. Der Brechungsindex von Single-Mode-Glasfaser liegt bei etwa 1,467, sodass Licht in Glasfaser mit c/1,467 ≈ 204.300 km/s läuft. Das ergibt einseitig rund 4,9 ms pro 1.000 km Glasfaser und einen Round-Trip von 9,8 ms. Das ist eine harte physikalische Untergrenze – kein Engineering kann die Lichtgeschwindigkeit unterbieten. Eine praktischere Faustregel für die Produktivplanung: 1 ms pro 100 km einseitig zuzüglich 1–2 ms Switching- und Routing-Aufwand pro Netzwerk-Hop. Lange Seekabel sind gut konstruiert und nähern sich dem theoretischen Minimum an (London–New York rund 70 ms RTT, nahe der 5.500-km-Großkreis-Grenze). Last-Mile- und innerstädtische Pfade liegen häufig bei 5–15 ms aufgrund von Router-Hops und ISP-Peering-Geometrie statt der Distanz.
Realistische RTT zwischen Großstädten
Ungefähre Round-Trip-Zeiten (volle RTT) zwischen großen Hosting-Hubs 2026: London–Amsterdam ~10 ms, London–Frankfurt ~15 ms, London–New York ~70 ms, New York–San Francisco ~70 ms, Frankfurt–Singapur ~160 ms, London–Sydney ~250 ms, Tokio–San Francisco ~100 ms. Das sind typische Glasfaser-Best-Case-Werte zwischen Rechenzentrums-Peers, gemessen TCP-zu-TCP.
Diese Werte basieren auf öffentlichen Peering-Daten der großen IXPs (LINX, AMS-IX, DE-CIX, KINX) und großen Latenz-Atlanten (RIPE Atlas, WonderNetwork, Cloudping). Ihre tatsächliche RTT variiert um 10–30 % je nach Tageszeit, Peering-Beziehungen zwischen Anbieter und Endnutzer-ISP sowie der konkret genutzten Seekabelroute. Die Zahlen sind typisch, nicht garantiert, und setzen voraus, dass beide Endpunkte in Rechenzentren mit Multi-Tbps-Transit liegen. Last-Mile-Privatanschlüsse erhöhen die Latenz zusätzlich um 5–30 ms gegenüber dem Rechenzentrum-zu-Rechenzentrum-Niveau.
| Von | Nach | Distanz (Großkreis) | Typische RTT |
|---|---|---|---|
| London | Amsterdam | 360 km | ≈ 10 ms |
| London | Frankfurt | 640 km | ≈ 15 ms |
| London | Paris | 340 km | ≈ 10 ms |
| Frankfurt | Warschau | 900 km | ≈ 20 ms |
| London | New York | 5.570 km | ≈ 70 ms |
| New York | Miami | 1.760 km | ≈ 30 ms |
| New York | San Francisco | 4.140 km | ≈ 70 ms |
| San Francisco | Tokio | 8.280 km | ≈ 100 ms |
| Frankfurt | Singapur | 10.290 km | ≈ 160 ms |
| London | Sydney | 16.990 km | ≈ 250 ms |
| Frankfurt | Mumbai | 6.580 km | ≈ 110 ms |
| São Paulo | Miami | 6.580 km | ≈ 120 ms |
Datenresidenz: DSGVO, CLOUD Act und der Rest
Personenbezogene Daten von EU-/EWR-Bürgern unterliegen der DSGVO (Verordnung (EU) 2016/679), die Übermittlungen außerhalb des EWR ohne besondere Schutzgarantien beschränkt. Der US CLOUD Act (2018) verpflichtet US-ansässige Anbieter, Daten herauszugeben, unabhängig vom physischen Speicherort. Russland und China haben eigene Lokalisierungs-Regime. Wählen Sie einen Standort, der zu den Rechtsräumen Ihrer Nutzer und Ihren vertraglichen Pflichten passt.
Die DSGVO (wirksam seit Mai 2018) behandelt personenbezogene Daten von EU- oder EWR-Einwohnern – Name, E-Mail, IP-Adresse, Verhaltensdaten – als reguliert, unabhängig vom Sitz des Verantwortlichen. Datenübermittlungen in Drittländer erfordern einen Angemessenheitsbeschluss, Standardvertragsklauseln oder Binding Corporate Rules. Artikel-49-Ausnahmen sind eng. Das Schrems-II-Urteil (EuGH, Juli 2020) kippte den Privacy Shield und verschärfte die Anforderungen an Übermittlungen erheblich. Der US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) verpflichtet US-Bundesbehörden, jeden in den USA ansässigen Anbieter zur Herausgabe gespeicherter Daten zu zwingen, selbst wenn die Daten auf einem Server in Frankfurt liegen. Daraus entsteht für europäische Kunden, die US-ansässige Hosting-Anbieter nutzen, eine Spannung – unabhängig vom physischen Standort der Daten. Das russische Föderationsgesetz Nr. 242-FZ verlangt, personenbezogene Daten russischer Staatsbürger zunächst auf Servern in Russland zu verarbeiten. Das chinesische PIPL (Personal Information Protection Law, wirksam seit November 2021) verlangt Lokalisierung für Betreiber kritischer Informationsinfrastruktur und für Großverarbeiter. Keinem Regime sind die Standorte Ihrer Anwendungs-Server wichtig; allen ist wichtig, wo personenbezogene Daten gespeichert und verarbeitet werden.
Wann Multi-Region sinnvoll ist
Multi-Region ist gerechtfertigt bei geografisch verteilten Nutzern mit Latenzanforderungen unter 100 ms, bei regulatorischen Datenresidenz-Pflichten über mehrere Rechtsräume hinweg oder wenn das Risiko eines einzelnen regionalen Ausfalls inakzeptabel ist. Selten gerechtfertigt ist es bei Hobbyprojekten, traffic-armen SaaS in einer Region oder Workloads, in denen der Engineering-Aufwand den Latenzgewinn überwiegt.
Multi-Region bringt drei konkrete Kosten. Erstens Engineering-Komplexität: Datenreplikation (eventuell konsistent oder global synchron), Routing-Logik (Geo-DNS, Anycast, regionales Failover) und Observability über Regionen hinweg vervielfachen die Betriebsfläche. Zweitens Infrastrukturkosten: mindestens doppelt so viele Compute- und Storage-Ressourcen sowie Inter-Region-Transitgebühren der Cloud-Anbieter pro GB. Drittens Konsistenz-Kompromisse: synchrone globale Schreibvorgänge sind durch dieselbe Latenzmathematik begrenzt; die meisten Multi-Region-Designs akzeptieren eine Form von Eventual Consistency. Lohnenswert sind diese Kosten bei: real auf mehrere Kontinente verteilten Nutzern, bei denen 200+ ms RTT Conversion zerstören; RTO-Anforderungen unter einer Sekunde; gleichzeitigen Pflichten, EU-Daten in der EU und US-Daten in den USA zu halten; oder Active-Active-HA-Anforderungen, in denen ein einzelner Rechenzentrumsausfall unsichtbar bleiben muss. Die meisten Produktiv-Workloads benötigen das nicht; viele Designs überdimensionieren in diese Richtung.
Entscheidungsbaum: Wie Sie eine Region wählen
Schritt 1: Stellen Sie fest, wo 80 % Ihrer Nutzer leben (Analytics, CDN-Logs, erwarteter Markt). Schritt 2: Wählen Sie die nächstgelegene Hosting-Region. Schritt 3: Prüfen Sie, ob die Rechtsordnung Ihren Datenresidenz-Pflichten entspricht. Schritt 4: Fügen Sie nur dann eine zweite Region hinzu, wenn Schritt 1 ein zweites Nutzercluster mit mehr als 100 ms RTT zur ersten Region ergibt oder HA/DR-Anforderungen es verlangen.
Gehen Sie den Baum ehrlich durch. Für eine typische europäisch fokussierte SaaS-Anwendung mit Nutzern überwiegend in Deutschland, Frankreich, dem Vereinigten Königreich und den Niederlanden hält ein einzelnes westeuropäisches Rechenzentrum (Frankfurt, Amsterdam oder London) jeden Nutzer unter 30 ms RTT und erfüllt die DSGVO sauber. Für ein US-fokussiertes B2B-Produkt mit Nutzern von Boston bis Los Angeles hält ein einzelnes US-Ostküsten-Rechenzentrum (Ashburn, NYC) Ostküsten-Nutzer unter 20 ms und Westküsten-Nutzer unter 80 ms – schlecht für Gaming, ausreichend für die meisten SaaS-Anwendungen. Für wirklich globale Produkte (Webanwendungen mit Nutzern auf jedem Kontinent) schlägt eine Primärregion mit globalem CDN meist Active-Active in drei Rechenzentren. Für Produkte mit harten Datenresidenz-Anforderungen über Rechtsräume hinweg (separate EU- und US-Datenpfade) wird Multi-Region unabhängig von der Latenz Pflicht.
Compliance-Kürzel: Zertifikate, die wirklich etwas bedeuten
Achten Sie auf ISO/IEC 27001 (Informationssicherheits-Managementsystem), SOC 2 Type II (über die Zeit auditierte Kontrollen, nicht punktuell) sowie PCI DSS Level 1 (Zahlungsdaten), sofern relevant. Für EU-Kunden sind ausdrückliche DSGVO-Auftragsverarbeitungsverträge (AVVs) und eine klare Liste der Subverarbeiter wichtig. Generische „Sicherheit auf Enterprise-Niveau“-Aussagen ohne konkrete Zertifizierungen sind im Wesentlichen bedeutungslos.
Drei Zertifizierungen haben echtes Gewicht. ISO/IEC 27001:2022 ist der internationale Standard für Informationssicherheits-Managementsysteme und verlangt eine unabhängige Zertifizierung sowie laufende Überwachungsaudits. SOC 2 Type II bewertet die Kontrollen einer Organisation über einen 6–12-Monats-Beobachtungszeitraum, im Gegensatz zu Typ I (Stichtag). PCI DSS gilt, wenn Sie Zahlungskarten verarbeiten; Level 1 betrifft Organisationen mit über 6 Millionen Transaktionen pro Jahr. Für EU-Kunden ist der DSGVO-AVV vertraglich bindend und legt fest, was der Anbieter mit Ihren Daten darf und nicht darf. Darüber hinaus achten Sie auf Transparenzberichte (wie häufig erhält der Anbieter behördliche Anfragen?), eine veröffentlichte Liste der Subverarbeiter (Dritte mit Datenzugriff) und eindeutige Löschzusagen bei Vertragsende. Generische Floskeln wie „Sicherheit auf Bankenniveau“ oder „militärische Verschlüsselung“ sagen nichts – das zugrunde liegende AES-256 ist überall identisch.