Designing Cloud Workloads For LEO Satellite Internet Users#

Sid Mathur – Fastah Inc.

• Why: LEO connectivity is quietly becoming a real user population, and it breaks assumptions (stable egress, stable IP geo, predictable RTT) that most cloud architecture takes for granted.
• What: A mental model and design-pattern set for LEO-served users: traffic lands at ~200 (Starlink) / 300+ planned (Amazon LEO) ground gateways mapped to IX/PoPs; static users behave like fixed broadband, while in-motion users (aviation, maritime) change egress mid-session — the talk traces one flight's IP geolocation through Qatar, Kuwait, Jordan, Bulgaria, Hungary, Germany, and France, with all the GDPR/jurisdiction questions that implies. Amazon LEO B2B rides AWS Direct Connect, so once traffic lands it's ordinary VPC traffic; new multicloud interconnects (AWS Interconnect Multicloud, GCP Cross-cloud Interconnect) enable cross-cloud failover patterns.
• How: Three patterns — pin static low-latency users to the nearest region with PNI for predictable RTT; build in-motion users as multi-region active-active with stateless services and HTTP/3 tolerance for TLS/TCP resets; use cross-cloud interconnects for "too expensive to fail" B2B workloads. Decision inputs: user-population geography, data sovereignty, egress cost, latency budget, failover topology.
• Where applicable: Teams building applications for LEO user populations; the interconnect specifics are AWS/GCP-specific. Key takeaway: the routing path is the only truly different part.