Why the region you pick matters (and how to pick one)
Every DeskBoot session runs in exactly one AWS region. Which region you pick is the single biggest factor in whether your session feels responsive over RDP — bigger than the OS choice, bigger than the instance size, bigger than any tuning setting. It's the one decision worth thinking about for a moment.
Why RDP is unusually sensitive to distance
Round-trip time (RTT) is the milliseconds it takes a packet to leave your machine, reach the server, and come back. Watching a video? RTT barely matters — the buffer smooths it out. Loading a webpage? A little sluggish above 200ms but tolerable. Typing into a remote desktop? Every keypress and every mouse move is a round trip. Above about 80ms of RTT, most people start noticing lag. Above 200ms, it feels distinctly bad.
That's just physics — light in a fiber cable moves at about two-thirds the speed of light in vacuum, and packets pass through routers along the way that each add a millisecond or two. There's no CDN or "edge network" trick that speeds up an interactive session, because the packets have to make the full round trip.
Rough RTT to each region
Approximate round-trip times to each of the regions DeskBoot supports, from a handful of representative cities on well-peered ISPs. Yours will vary with your local carrier, but the shape is right — orders of magnitude difference between "close" and "far".
| From | To Cape Town (af-south-1) | To Virginia (us-east-1) | To Ohio (us-east-2) | To Dublin (eu-west-1) | To Mumbai (ap-south-1) |
|---|---|---|---|---|---|
| Cape Town | ~5 ms | ~230 ms | ~215 ms | ~155 ms | ~250 ms |
| Nairobi | ~130 ms | ~280 ms | ~275 ms | ~170 ms | ~150 ms |
| Lagos | ~120 ms | ~150 ms | ~140 ms | ~90 ms | ~200 ms |
| New York | ~200 ms | ~10 ms | ~25 ms | ~75 ms | ~230 ms |
| San Francisco | ~250 ms | ~70 ms | ~55 ms | ~140 ms | ~230 ms |
| London | ~150 ms | ~75 ms | ~90 ms | ~15 ms | ~110 ms |
| Berlin | ~170 ms | ~90 ms | ~105 ms | ~30 ms | ~120 ms |
| Mumbai | ~250 ms | ~230 ms | ~215 ms | ~110 ms | ~5 ms |
| Singapore | ~330 ms | ~230 ms | ~215 ms | ~180 ms | ~65 ms |
The pattern is the same everywhere: pick the region physically closest to you, RDP feels great. Pick one far away, RDP starts to feel like you're typing through molasses.
Practical rules of thumb
- Somewhere in Africa? af-south-1 (Cape Town) if you're anywhere south of the Sahara. Central + West Africa also gets a solid experience from eu-west-1 (Dublin) since undersea cables to Europe are well-peered.
- Europe or Middle East? eu-west-1 (Dublin).
- North America east coast? us-east-1 (Virginia).
- North America central + west coast? us-east-2 (Ohio) shaves a few ms over Virginia for central users; for the actual west coast, both regions are compromises.
- South Asia? ap-south-1 (Mumbai).
- East Asia + Oceania? ap-south-1 (Mumbai) is the closest we currently offer — request another region via support and we'll evaluate.
Region matters for more than latency
A few smaller things also follow from your region choice:
- Data residency. Your encrypted disk lives in the region you launched in. It doesn't traverse other regions. Relevant if you have compliance rules about where customer data can sit.
- Static IP geolocation. If you attach an Elastic IP, its geolocation reflects the region — a Cape Town EIP looks like an African IP to services that geo-fence traffic, a Virginia EIP looks like a US IP, etc.
- Cost is uniform across regions on DeskBoot. Some cloud providers price differently per region; we don't. Pick the one closest to you without checking the invoice implications.
The takeaway
Pick the region closest to where your fingers are. That's the whole decision. Everything else — OS, size, whether to add a static IP — is easier to reverse than the region, because switching regions means launching a new session (a few clicks, but not free). Get the region right the first time.
Comments (0)
Want to try DeskBoot? First 50 testers get $50 in credits. Sign up at deskboot.store or send a message via /contact for a voucher code.