"The cloud is slow" is rarely about the cloud. It's about the path between you and it: the region you picked three years ago for reasons nobody remembers, a DNS resolver that routes you to the wrong front door, or office traffic taking a scenic tour through a VPN concentrator on another continent.
The good news is that the path is measurable, and most of the wins come from a handful of decisions you can revisit in an afternoon. This guide works through them in order of impact.
Step 1. Measure before you change anything
You can't optimise what you haven't measured, and intuition about latency is consistently wrong. Establish a baseline:
- Run a ping test against the cloud endpoints you actually use - your API hostname, your database's public endpoint, the provider's regional endpoint (e.g.
ec2.eu-west-1.amazonaws.com). Record min/avg/max and packet loss. - Test at different times of day. A path that's clean at 9am and lossy at 8pm points at congestion (often your ISP or office uplink), not the cloud provider.
- Note the physics floor: light in fibre gives you roughly 1 ms of round-trip time per 100 km, and real routes are never straight lines. London to
us-east-1will never be under ~70 ms RTT no matter what you tune. If your measured latency is close to the geographic minimum, region choice is your only lever. If it's far above it, the path is fixable.
Keep the numbers. Every change in the following steps gets validated against this baseline, not against vibes.
Step 2. Verify where you're actually connecting
Cloud providers front their services with regional and sometimes anycast endpoints. Before judging a region "slow", confirm you're talking to the one you think you are.
- Resolve the service hostname with the DNS Lookup tool and put the returned IP into IP Geolocation. The ASN will confirm the provider; the location tells you which front door you've been routed to.
- For multi-region or global-accelerator endpoints, geolocation of the entry point matters less (you enter the provider's backbone near you), but for a plain regional endpoint, an IP that geolocates to Virginia when you meant Frankfurt explains a lot.
- Be aware geolocation databases are approximate for cloud ranges - treat country/region as reliable, city as a hint.
This step regularly turns up surprises: a "EU" deployment whose storage bucket is in us-east-1, or a third-party API that's single-homed on the other side of the planet.
Step 3. Pick regions with data, not defaults
Region selection is the biggest single latency lever you have, and it's commonly decided once, by default, at project creation.
- Ping each candidate region's endpoint from where your users and offices actually are. Providers publish per-region endpoint hostnames precisely so you can do this.
- Optimise for where the traffic originates, not where the company is headquartered. If 70% of requests come from Southeast Asia,
ap-southeast-1beatsus-west-2even if the engineering team is in California. - Keep chatty components in the same region - and the same zone where the architecture allows. A request that fans out into 20 sequential intra-app calls multiplies any inter-region latency by 20. Cross-region database calls are the classic offender: 1 ms becomes 80 ms per query, and an ORM that lazily loads in a loop turns that into seconds.
- If users are genuinely global, one region won't cut it. CDN for static and cacheable content first (cheapest), then multi-region read replicas, then full multi-region active-active (expensive, do it last).
Step 4. Fix DNS resolution
DNS affects cloud latency twice: the resolution itself adds to every cold connection, and for latency-based or geo-DNS services, which resolver you use determines which endpoint you get.
- Latency-routed services answer based on where the query comes from - which is your resolver, not you (mitigated, but not eliminated, by EDNS Client Subnet support). An office in Madrid using a resolver that egresses in another country can be steered to the wrong regional endpoint on every lookup.
- Use a resolver close to your network: your ISP's, or a well-peered public resolver (1.1.1.1, 8.8.8.8). Test both - whichever returns answers fastest and steers you to the nearest endpoint wins. Compare what each resolver returns for your latency-routed hostnames using a DNS lookup; the walkthrough in how to perform a DNS lookup covers reading the results.
- Inside the cloud, use the provider's internal resolver (e.g. the VPC resolver) so service hostnames resolve to private endpoints and traffic stays on the internal network instead of hairpinning through public IPs.
- Respect TTLs in your application: re-resolving on every request adds latency; never re-resolving breaks failover. Long-lived runtimes (notably the JVM with default settings) are infamous for caching answers past their TTL.
Step 5. Straighten the egress path
How traffic leaves your network for the cloud is the layer most organisations never look at.
- Local internet breakout. If branch-office traffic backhauls through a central VPN/MPLS hub before reaching the internet, every cloud request pays the detour. Letting cloud-bound traffic egress locally (split tunnelling for VPN users, local breakout for branches) is often worth tens of milliseconds per round trip.
- Dedicated interconnects. AWS Direct Connect, Azure ExpressRoute, and Google Cloud Interconnect give you a private circuit into the provider. The win is less raw speed than consistency: no public-internet congestion, flat latency and jitter. Justified for sustained heavy traffic, hybrid workloads, or compliance - not for a small office consuming SaaS.
- Provider backbones from the edge. Global accelerator products (AWS Global Accelerator, Cloudflare Argo and similar) use anycast to pull your traffic onto the provider's private backbone at the nearest edge, bypassing long public-internet routes. Cheap to trial; measure against your Step 1 baseline.
- Inside the cloud, prefer private endpoints (VPC endpoints / Private Link / Private Service Connect) over routing to a service's public IP through a NAT gateway - shorter path, and usually cheaper on egress charges too.
Step 6. Cache and keep connections warm
Once the path is as short as it gets, send less traffic over it and pay setup costs less often:
- A fresh HTTPS connection costs at least two round trips (TCP + TLS 1.3) before any data moves. At 80 ms RTT that's 160 ms of pure overhead per cold connection. Use keep-alive and connection pooling everywhere; check your HTTP client's defaults rather than assuming.
- Put a CDN in front of anything cacheable, including API responses with short TTLs where correctness allows.
- Cache near the consumer: an in-region Redis in front of a cross-region database turns 80 ms reads into sub-millisecond ones.
- Batch chatty protocols. One request carrying 50 items beats 50 requests carrying one, in direct proportion to your RTT.
Step 7. Re-measure and keep watching
Re-run the Step 1 measurements after each change and keep the deltas. Latency regressions creep in silently - a new dependency in a distant region, an ISP route change, a VPN policy update that re-enables full tunnelling. Re-baseline quarterly, and after any network or architecture change, so "the cloud feels slow lately" comes with numbers attached.
TL;DR
- Baseline with a ping test to your real endpoints; respect the geographic latency floor.
- Confirm where you're actually connecting with DNS lookup + IP geolocation.
- Choose regions by measured latency from where traffic originates; keep chatty components co-located.
- Use a fast, well-located resolver - it decides which endpoint geo/latency-routed services give you.
- Egress locally instead of backhauling; consider dedicated interconnects or backbone accelerators for sustained loads.
- Pool connections, cache near consumers, batch chatty calls.
- Re-measure after every change and re-baseline quarterly.