Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / How Cloud Regions Are Competing on Latency Not Just Price
Transcript
- Lucas: Alright, so you hear a lot about cloud price wars — AWS drops compute by five percent, Azure matches, Google follows. But look at the actual contract negotiations happening in enterprise right now, June 2026. The big three are shifting the conversation away from price and toward something harder to compare: latency. Luna: And by latency you mean the actual round-trip time for data to travel from the enterprise's location to the cloud region and back. Lucas: Exactly. And it matters way more than it did five years ago because of AI inference. A model that's doing real-time fraud detection or live translation — every ten milliseconds of extra latency changes the user experience. So providers are racing to put infrastructure closer to where the data lives, not just where it's cheapest to run. Luna: Give me a concrete example of a region that's winning on that front. Lucas: Sure. Take AWS's newer edge locations in secondary cities like Columbus, Ohio and Omaha, Nebraska. These launched late last year as part of a broader push called 'Local Zones 2.0'. Before that, a company based in Des Moines would hit us-east-1 in Northern Virginia, which is about 900 miles away. That round-trip time was around 40 to 50 milliseconds. Luna: And now with the edge cache in Chicago or the Columbus local zone, they can cut that by maybe 30 milliseconds. Lucas: Right. A fintech firm I talked to — they process payment authorizations for midwest credit unions — switched from routing everything through us-east-1 to using the Columbus local zone with a small compute footprint. Their average API response time dropped by 40 percent. That's the difference between a transaction timing out and going through. Luna: So the cloud providers are essentially building last-mile infrastructure, like what telcos did for fiber. Lucas: That's exactly the analogy. And the interesting thing is how Google Cloud is positioning its network as a differentiator. They've been saying for years that their backbone is the best in class because they own the fiber between all their regions. Now they're backing it with numbers — they published a study in early 2026 showing that for workloads in the central US, their round-trip time from Chicago to their Iowa region is 14 milliseconds, versus AWS's 22 milliseconds from Chicago to us-east-2 in Ohio. Luna: Eight milliseconds doesn't sound like a lot, but in high-frequency trading or real-time recommendation engines, that's a lifetime. Lucas: Exactly. And Azure is responding with something called 'Express Routing Zones' — they're essentially putting dedicated routing hardware inside select colocation facilities in places like Dallas and Atlanta, so that enterprise traffic doesn't have to go all the way back to a regional Azure gateway. It shaves off 5 to 15 milliseconds depending on the path. Luna: So the competitive moat is shifting from 'we have the cheapest compute' to 'our network gets you there faster'. How are enterprises actually baking that into their cloud contracts? Lucas: That's where it gets really practical. In 2026, more cloud contracts include latency SLAs. Not just uptime — specific performance thresholds for round-trip time at the 99.5th percentile. If the provider misses that, they issue credits. I've seen clauses where if latency exceeds 30 milliseconds for more than 0.5 percent of measured traffic over a month, the enterprise gets a 10 percent discount on that region's compute bill. Luna: That's a big shift from the old 'five nines of availability' SLA that didn't say anything about speed. Lucas: Right. And it puts pressure on the providers to be honest about their network topology. Because if you sign a contract that guarantees latency to a specific metro area, the provider has to commit to keeping traffic within a certain path. They can't just route you to a cheaper region on the other side of the country. Luna: Which also means that enterprise architects have to understand their own traffic patterns better. If you don't know where your users are, you can't negotiate the right SLA. Lucas: Absolutely. And this is something that comes up a lot in our conversations with listeners. Speaking of which — if today's episode was useful for understanding how cloud providers are competing on latency, or if you're someone who builds or runs infrastructure and these details help you make better decisions, the way this show stays ad-free is through listener support. You can find that at buy me a coffee dot com slash fexingo. It's a small way to keep these conversations going without any sponsor interruptions. Luna: Yeah, and we really appreciate everyone who's contributed. It lets us focus on the stuff that actually matters for operators and builders, not on selling ad slots. Lucas: Alright, back to the network competition. The other dimension I want to dig into is how latency concerns are changing where enterprises choose to put their primary workloads. I'm seeing a trend away from the big hubs — us-east-1, eu-west-2 — toward secondary regions that are closer to user bases. Luna: Can you name a specific region that's benefiting from that shift? Lucas: Sure. Take Azure's South Central US region in Texas. Historically it was a disaster recovery option, not a primary site. But now with the new Express Routing Zones in Dallas, I'm seeing healthcare companies based in Houston and San Antonio using it as their primary region for electronic health record workloads. They're getting 10 to 15 milliseconds better latency than going to us-east-1. Luna: And that matters for clinicians accessing patient data in real time during a consult. Lucas: Exactly. One hospital network I spoke with said their Epic EHR portal load time went from 3.2 seconds to 1.8 seconds after moving primary compute to South Central US with an Express Route direct connection. That's a huge improvement in user experience. Luna: So the providers are essentially courting vertical-specific workloads by optimizing latency for particular geographies. Lucas: Yes, and it's not just healthcare. Financial services firms in the Midwest are doing the same thing. There's a brokerage in Kansas City that moved its risk calculation workloads to Google Cloud's Iowa region specifically because the latency to their trading systems in Chicago was 4 milliseconds better than going to AWS's Ohio region. That four milliseconds translates to real dollars in arbitrage opportunities. Luna: It's almost like a localized version of what we saw with high-frequency trading firms co-locating next to exchange servers. Lucas: Exactly. And the cloud providers are now competing on that same principle. They're building out 'micro-regions' — smaller data center footprints in cities that aren't traditional cloud hubs. AWS announced plans for local zones in 32 new US cities by the end of 2027, including places like Boise, Idaho and Knoxville, Tennessee. Luna: Those aren't places where you'd expect massive data centers. But they're close to regional enterprise hubs. Lucas: Right. And the economics work because the hardware is smaller — maybe 20 to 50 racks — and it's connected via high-bandwidth fiber to a larger region nearby. So the enterprise gets low latency without the provider having to build a full region. Luna: What about the cost trade-off? Is there a premium for being close to a local zone versus using a main region? Lucas: There is a premium, but it's shrinking. AWS's local zones were initially priced about 20 percent higher than the parent region for compute. By mid-2026, that gap has narrowed to around 10 percent for committed-use contracts. And enterprises are willing to pay that because the latency savings translate into better application performance and lower data transfer costs. Luna: Because if your compute is closer to your users, you're not paying for data egress across long distances. Lucas: Exactly. And that's the hidden math. The egress tax from us-east-1 to a user in Omaha can be significant. If you move the compute to a local zone in Chicago, the data path is shorter, so egress costs drop. I've seen cases where the total cost of ownership including egress is actually lower with a local zone than with the main region, despite the compute premium. Luna: So the conversation is shifting from 'which region is cheapest per compute hour' to 'where is the optimal location for my specific traffic pattern.' Lucas: Exactly. And that's a much more nuanced decision. It requires enterprises to actually map their user latency requirements and data flows. A lot of companies are using tools like Cedexis or Catchpoint to measure real round-trip times from their user base to different cloud regions before making a decision. Luna: That's a big change from five years ago when most companies just picked us-east-1 because that's what everyone did. Lucas: Right. And providers are incentivizing this shift. Google Cloud's network service tier lets you choose between standard and premium network routing. Premium routes traffic over Google's backbone for better latency, and they've reduced the premium pricing by 15 percent this year to encourage adoption. Luna: Are there any downsides to this latency arms race? Like, are we seeing fragmentation where workloads are spread too thin? Lucas: That's a real risk. If you distribute workloads across too many local zones, you lose the benefits of centralized management and bulk pricing. I've seen enterprises with 15 local zones where each one has underutilized reserved instances. The key is to find the balance between latency optimization and operational efficiency. Luna: So the smart play is to use a few well-chosen regions and local zones, not a shotgun approach. Lucas: Exactly. And that's where the new cloud broker role we talked about in episode 26 comes in. A good broker can help you analyze your traffic patterns and negotiate latency SLAs with the providers. Some enterprises are even doing what's called 'latency arbitrage' — they run the same workload in two regions and route traffic to whichever one has lower latency at that moment. Luna: That's clever. But it adds complexity to the networking stack. Lucas: It does, but the tools have matured. Services like Azure Traffic Manager or AWS Route 53 latency-based routing make it manageable. And for AI inference workloads, some companies are using a multi-region approach where the model is replicated across two or three regions and the inference request goes to the one with the lowest current latency. Luna: That feels like where the real competitive advantage will be — not just having a fast network, but having the intelligence to use it optimally. Lucas: Exactly. And I think that's the next frontier. The providers that can offer not just low latency but dynamic routing that adapts to real-time conditions will win the enterprise AI workloads. Google Cloud is already talking about 'adaptive network routing' as a preview feature for 2027. Luna: So the cloud of 2027 will be less about static regions and more about a fluid network that routes based on performance. Lucas: That's my bet. And the enterprises that start mapping their latency requirements now will be ahead when those capabilities become standard. Because once every provider offers sub-10 millisecond latency to major metros, the differentiation will be in how intelligently they use that network. Luna: And that's a whole new conversation for another episode. Lucas: Indeed it is. For now, if you're evaluating cloud contracts, don't just look at the compute price list. Ask for the latency SLA. Test the round-trip time from your user locations. You might find that the cheapest region isn't actually the cheapest once you factor in performance. Luna: Good advice. I think a lot of listeners will be rethinking their region strategy after this. Lucas: I hope so. Thanks for listening, and we'll catch you next time.