The latency math: what physics imposes
Light in vacuum travels 299,792 km/s. Light in fiber-optic cable travels at roughly 2/3 that — about 200,000 km/s, or roughly 5 ms per 1,000 km one-way. Round-trip time (RTT) is double that: ~10 ms per 1,000 km of cable run. Real-world fiber paths are usually 1.3-2x the great-circle distance, so factor in extra latency for routing realities.
Light slows down in glass because of refractive index. The refractive index of single-mode fiber is approximately 1.467, so the speed of light in fiber is c/1.467 ≈ 204,300 km/s. That gives a one-way latency of about 4.9 ms per 1,000 km of fiber and a round-trip of 9.8 ms. This is a hard physical floor — no amount of provider engineering can beat the speed of light. A more useful rule of thumb for production planning: budget 1 ms per 100 km one-way, plus 1-2 ms of switching and routing overhead per network hop. Long-haul submarine cables are well-engineered and approach the theoretical minimum (London-New York is roughly 70 ms RTT, near the 5,500 km great-circle limit). Last-mile and intra-city paths are often 5-15 ms because of router hops and ISP peering geometry rather than distance.
Real RTT estimates between major cities
Approximate one-way round-trip times (full RTT) between major hosting hubs in 2026: London-Amsterdam ~10 ms, London-Frankfurt ~15 ms, London-New York ~70 ms, New York-San Francisco ~70 ms, Frankfurt-Singapore ~160 ms, London-Sydney ~250 ms, Tokyo-San Francisco ~100 ms. These are typical fiber-best-case values measured TCP-to-TCP between datacenter peers.
These numbers come from the public peering data published by major IXPs (LINX, AMS-IX, DE-CIX, KINX) and large-scale latency atlases (RIPE Atlas, WonderNetwork, Cloudping). Your real RTT will vary 10-30% depending on time of day, peering relationships between your provider and your user's ISP, and the specific submarine cable path used. The numbers above are typical, not guaranteed, and they assume both endpoints are in datacenters with multi-Tbps transit. Last-mile residential connections add another 5-30 ms on top of the datacenter-to-datacenter floor.
| From | To | Distance (great-circle) | Typical RTT |
|---|---|---|---|
| London | Amsterdam | 360 km | ~10 ms |
| London | Frankfurt | 640 km | ~15 ms |
| London | Paris | 340 km | ~10 ms |
| Frankfurt | Warsaw | 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 | Tokyo | 8,280 km | ~100 ms |
| Frankfurt | Singapore | 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 |
Data residency: GDPR, CLOUD Act, and the rest
EU/EEA personal data falls under the GDPR (Regulation (EU) 2016/679), which restricts transfers outside the EEA without specific safeguards. The US CLOUD Act (2018) lets US authorities compel US-headquartered providers to disclose data regardless of where it is physically stored. Russia and China have their own data-localization regimes. Pick a datacenter region that aligns with both your users' jurisdictions and your contractual obligations.
GDPR (effective May 2018) treats any personal data of EU or EEA residents — name, email, IP address, behavioral data — as regulated regardless of where the controller is headquartered. Cross-border transfers require an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules. Article 49 derogations are narrow. The Schrems II ruling (Court of Justice of the European Union, July 2020) struck down Privacy Shield and tightened transfer safeguards considerably. The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) lets US federal authorities compel any US-based provider to produce stored data, even if the data sits on a server in Frankfurt. This creates a tension for European customers using US-headquartered hosting providers, regardless of which datacenter their data physically lives in. Russian Federal Law No. 242-FZ requires personal data of Russian citizens to be processed initially on servers physically inside Russia. China's PIPL (Personal Information Protection Law, effective November 2021) requires localization for critical information infrastructure operators and for high-volume data processors. None of these regimes care where your application servers run; all of them care where personal data is stored and processed.
When multi-region makes sense
Multi-region is justified when you have geographically distributed users with sub-100-ms latency requirements, when you have regulatory data-residency obligations across jurisdictions, or when single-region downtime risk is unacceptable. It is rarely justified for hobby projects, low-traffic SaaS with users in one region, or workloads where engineering complexity outweighs latency gains.
Multi-region adds three concrete costs. First, engineering complexity: data replication (eventually-consistent or globally synchronous), routing logic (geo-DNS, anycast, regional failover), and observability across regions all multiply the operational surface area. Second, infrastructure cost: at least double the compute and storage, plus inter-region transit fees that cloud providers charge per GB. Third, consistency tradeoffs: synchronous global writes are physically limited by the same latency math from the previous section, so most multi-region designs accept some form of eventual consistency. The justifications worth that cost: real users distributed across continents where 200+ ms latency tanks conversion, sub-second-RTO disaster recovery requirements, regulatory obligations to keep EU data in the EU and US data in the US simultaneously, or active-active high-availability requirements where any single datacenter outage must be invisible. Most production workloads do not need it; many designs over-engineer toward it.
Decision tree: how to pick a region
Step 1: identify where 80% of your users live (analytics, CDN logs, expected target market). Step 2: pick the closest hosting region. Step 3: check legal jurisdiction matches your data-residency obligations. Step 4: only add a second region if step 1 reveals a second user cluster more than 100 ms RTT from the first, or if HA/DR requirements demand it.
Run through the tree honestly. For a typical European-focused SaaS with users mostly in Germany, France, the UK, and the Netherlands, a single Western European datacenter (Frankfurt, Amsterdam, or London) keeps every user under 30 ms RTT and satisfies GDPR cleanly. For a US-focused B2B product with users from Boston to Los Angeles, a single US East datacenter (Ashburn, NYC) keeps East-Coast users under 20 ms and West-Coast under 80 ms — bad for gaming, fine for most SaaS. For genuinely global products (web apps with users on every continent), a primary region plus a CDN with global edge presence usually beats running active-active in three datacenters. For products with hard data-residency requirements across jurisdictions (an EU-only and US-only data plane), multi-region becomes mandatory regardless of latency.
Compliance shortcuts: certifications that actually mean something
Look for ISO/IEC 27001 (information security management), SOC 2 Type II (operational controls audited over time, not at a single moment), and PCI DSS Level 1 (payment data) if those apply. For EU customers, look for explicit GDPR data-processing agreements (DPAs) and a clear list of sub-processors. Generic 'enterprise-grade security' marketing without named certifications is essentially meaningless.
Three certifications carry real weight. ISO/IEC 27001:2022 is the international standard for information security management systems and requires an independent audit and ongoing surveillance audits. SOC 2 Type II audits an organization's controls over a 6-12 month observation window, distinguishing it from Type I (point-in-time). PCI DSS applies if you handle payment cards; Level 1 is for organizations processing 6+ million transactions/year. For European customers, the GDPR DPA (data-processing addendum) is contractually binding and lists exactly what the provider can and cannot do with your data. Beyond those, look for transparency reports (how often does the provider receive law-enforcement requests?), a published list of sub-processors (third parties touching your data), and clear data-deletion guarantees on contract termination. Generic phrases like 'bank-grade security' or 'military-grade encryption' tell you nothing — the underlying AES-256 algorithm is the same everywhere.