Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Why Cloud Contracts Now Lock in Network Peering Commitments
Transcript
- Lucas: Luna, I just finished reading a cloud contract from a mid-sized fintech company, and buried in the networking addendum was a clause I hadn't seen before: a minimum annual commitment for direct peering bandwidth, with a penalty for falling short. Luna: Wait — a minimum for peering? I thought peering was just a flat port fee plus whatever traffic you actually send. Lucas: That used to be the case. But as more workloads — especially AI training — generate massive east-west traffic, cloud providers are locking in network commitments the same way they lock in compute reservations. The fintech I looked at, let's call them NexusPay, signed a three-year deal with Azure for 500 gigabits per second of ExpressRoute peering. Luna: And they have to pay for that 500 gigabit whether they use it or not? Lucas: Essentially yes. Though they did negotiate a clever rollover clause: any unused bandwidth in a given month converts to compute credits at a rate of one point two times the peering cost. So it's not pure waste, but it still locks them into a minimum networking spend that wasn't there three years ago. Luna: That's a big shift. I remember when peering was almost an afterthought in cloud negotiations — you'd pick your port size and pay as you go. Lucas: Right. Today, networking can account for 20 to 30 percent of a large enterprise's cloud bill. And with AI workloads shuttling terabytes of training data between GPU clusters, that share is climbing. Cloud providers see peering as a revenue lever they'd previously left on the table. Luna: It makes sense from their side. They're building out massive backbone capacity, and they want predictable usage to justify the capital expenditure. Lucas: Exactly. And the data gravity effect is real — once you've got a petabyte of training data in a region, you're not moving it easily. The providers know that, so they're baking the network commitment into the contract terms. Luna: We keep these conversations accessible and ad-free because we think operators and builders should have this context without paywalls. If that's useful to you, the link to support the show is buy me a coffee dot com slash fexingo. Lucas: Yeah, we hear from listeners who say these contract details save them real money when they sit down with their cloud reps. That's why we do it. Luna: So back to NexusPay — how did they end up with that rollover clause? Lucas: They had a good negotiator who pointed out that their traffic patterns are seasonal: heavy during the last week of each month when they run model retraining, lighter otherwise. Azure agreed to the credit rollover because NexusPay also committed to using Azure's native AI services for that training. Luna: Right, it's a bundle. You get a break on peering if you lock in compute. Lucas: Precisely. And this is becoming a pattern. I've seen similar structures from AWS Direct Connect and Google Cloud Interconnect. The providers are basically saying: we'll give you a per-gigabit discount on the port, but only if you sign a multi-year commitment with a minimum. Luna: What does that minimum look like in practice? Is it a percentage of the port capacity? Lucas: Typically it's 70 to 80 percent of the provisioned bandwidth. So if you buy a 100-gig port, you agree to push at least 70 gigs on average. Fall below that and you pay a penalty equal to the cost of the unused capacity. Luna: That's steep. For a company that's still scaling its AI workloads, that could be risky if adoption doesn't hit projections. Lucas: It's a risk. But the flip side is that committing to higher bandwidth gives you a lower per-gig rate. One enterprise I talked to saved 40 percent on their peering costs by moving from a 200-gig port to a 400-gig port with a 75 percent minimum. Luna: So it's a bet on growth. If you're confident your traffic will increase, you win. Lucas: Exactly. And the cloud providers are also adding clauses that let you burst above your committed rate during peak periods, at a premium. So it's not like you're capped. Luna: What about multi-cloud setups? If you're peering with two providers, you have to commit to both? Lucas: That's where it gets interesting. Companies like NexusPay use third-party interconnection platforms — Equinix Fabric, Megaport — to manage peering across clouds. Those platforms now offer aggregated commitments: you commit to a total bandwidth across all your cloud interconnects, and they distribute it dynamically. Luna: So you get one contract with the fabric provider instead of three separate ones with AWS, Azure, and Google? Lucas: Yes. And the fabric providers are also offering their own version of rollover credits. Megaport, for instance, has a 'bandwidth pool' that lets you shift unused capacity from one cloud to another. Luna: That's smart. It gives enterprises more flexibility than going direct. Lucas: But it also means you're now negotiating with an intermediary. And the intermediaries have their own minimums. One Equinix Fabric customer told me they had to commit to 200 gigs across all their virtual connections before they got the discounted port pricing. Luna: So the commitment model is cascading. The cloud providers push it to the fabric providers, who push it to the enterprise. Lucas: Exactly. And it's not just large enterprises. Medium-sized companies are now being asked to commit to 10- to 50-gig peering agreements. That's a new threshold. Luna: What about SLAs? Are they getting tighter as well? Lucas: Yes. The standard cloud SLA for direct peering used to be 99.9 percent uptime. Now some contracts are offering 99.99 percent — but only if you commit to a redundant configuration with two separate interconnects and a minimum of 100 gigs each. Luna: So you pay more for higher reliability, and you lock into a minimum to get that tier. Lucas: Right. And the penalties for missing the SLA are changing too. Instead of service credits, some providers now offer a direct billing reduction if uptime falls below the threshold. That's more valuable to enterprises. Luna: Interesting. I want to come back to the AI angle. How does training traffic specifically drive these peering commitments? Lucas: AI training is very chatty. When you train a large model across multiple GPU clusters, you're constantly moving gradients and parameters. That traffic can consume 50 to 100 gigabits per second just within a region. And if you're doing distributed training across regions, that traffic has to go over peering links. Luna: So cloud providers are essentially monetizing the AI boom through networking, not just compute. Lucas: Exactly. One hyperscaler told me that their peering revenue from AI customers grew 150 percent year-over-year last quarter. That's outpacing compute growth for those same customers. Luna: And do these ai specific peering deals have different terms? Lucas: They often include a 'training burst' clause — you can temporarily double your bandwidth during model training cycles at a 10 percent premium, rather than committing to the higher rate year-round. Luna: That's a good fit for the on-again, off-again nature of AI development. Lucas: Exactly. And some contracts now tie peering commitments to GPU reservations. If you reserve a certain number of GPUs, you get a discounted peering rate. It's all about locking in the relationship. Luna: What about the hybrid cloud scenario? Where you have on-premises data centers connected to the cloud? Lucas: Those are actually the most complex. One large bank I spoke with has a 400-gig peering link to AWS from their main data center. They signed a five-year deal with a 90 percent minimum. But they also run workloads on Azure, so they have a separate 200-gig link there. Luna: So they're effectively double-committed, with limited ability to shift traffic between clouds. Lucas: Right. And that's where the fabric providers come in. That bank is now considering using Equinix Fabric to consolidate their peering, so they can have a single 600-gig commitment across both clouds, with the flexibility to allocate bandwidth dynamically. Luna: That sounds like a smarter approach. But I imagine the contract negotiations with the fabric provider are just as intense. Lucas: They are. But there's a new trend: some enterprises are forming purchasing consortia to negotiate better peering terms. A group of five midsize companies in the same vertical — say, healthcare — pool their bandwidth commitments to get a higher volume discount from a fabric provider. Luna: That's fascinating. Collective bargaining for cloud networking. Lucas: It's early days, but I've seen it work. One consortium of three fintechs got a 25 percent discount on Equinix Fabric ports by committing to a combined 300 gigs. Luna: So if you're a smaller company, you're not necessarily locked out of these deals. You just need to find partners. Lucas: Exactly. And the providers are open to it because it gives them predictable revenue from a larger customer base. Luna: Looking ahead, do you see these peering commitments becoming as standard as reserved instances? Lucas: I do. In fact, I think within two years, any enterprise cloud contract over a certain size will include a networking commitment. The data gravity and AI traffic are only going to increase. Luna: So the takeaway for listeners: when you sit down to negotiate your next cloud deal, make sure you're thinking about peering as a first-class item, not an afterthought. Lucas: Exactly. Ask about minimums, rollover credits, burst options, and whether a fabric provider could give you more flexibility. The terms are negotiable — but only if you know to ask. Luna: Good advice. Thanks, Lucas. Lucas: Thanks, Luna. We'll be back next time with another angle.