Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Cloud Contracts Now Charge for Multi-Cloud Egress Routing
Transcript
- Lucas: So you’re building a multi-cloud architecture — maybe AWS for compute, GCP for BigQuery, Azure for Active Directory — and you think, great, I’ll route traffic through whichever cloud has the cheapest egress to the user. Luna: Right. That’s the whole promise of multi-cloud, isn’t it? Pick the best service for each job. Lucas: Exactly. But recently, both AWS and Google Cloud have added a new line item to their contracts: a charge for egress routing decisions. It’s not just about how much data leaves your VPC — it’s about where it goes before it reaches the internet. Luna: Wait — so they’re charging based on the path the traffic takes? Not just the volume? Lucas: That’s right. Let me give you a concrete example. There’s a mid-sized fintech company — let’s call them PayFlow — that runs their application layer on AWS in us-east-1, but their analytics platform lives in GCP us-central1. Users hit the app, and some of that traffic gets redirected to GCP for an analytics query. Luna: So the traffic leaves AWS, goes to GCP, then goes out to the user from GCP. Lucas: Exactly. Under the old contract model, PayFlow would pay egress from AWS to GCP — that’s inter-region data transfer, which is about 2 to 4 cents per gigabyte. Then they’d pay egress from GCP to the user — another 8 to 12 cents per gig. The routing decision itself didn’t have a separate fee. Luna: But now there’s a charge for the fact that the traffic took two hops instead of one? Lucas: Yes. AWS started this in late 2025. They introduced what they call a 'Routing Complexity Fee' on certain traffic types that transit through their network to another cloud before hitting the internet. It’s a flat five cents per gigabyte on top of the existing egress charge. Luna: So that second hop now costs an extra 40 to 60 percent on top of the data transfer itself. Lucas: And Google Cloud followed suit earlier this year. Their version is called 'Multi-Cloud Routing Surcharge' — same idea, but they apply it when traffic egresses from GCP to another cloud provider before going to the user. They charge an additional two cents per gig. Luna: Why the difference in pricing? Is AWS just being more aggressive? Lucas: It’s partly a reflection of how their networks are designed. AWS has a more complex regional mesh, so routing traffic through multiple clouds adds more load on their backbone. But I think the real reason is strategic — both companies want to discourage you from routing traffic through a competitor before it reaches the user. Luna: So it’s a lock-in play disguised as a cost-recovery fee. Lucas: Exactly. Microsoft Azure hasn’t announced a similar fee yet, but I’d be surprised if they don’t follow within the next six months. The pattern is clear: if your traffic touches another cloud, you’re going to pay a premium. Luna: Let’s go back to PayFlow. How much did this cost them in practice? Lucas: PayFlow was moving about 200 terabytes a month through that aws to gcp to user path. Under the old pricing, their AWS egress to GCP was about 2 cents per gig — that’s $4,000. Their GCP egress to users was 10 cents per gig — $20,000. Total: $24,000 a month. Luna: And now? Lucas: With the AWS routing fee of 5 cents per gig on that 200 terabytes, that’s an additional $10,000. Plus the GCP surcharge of 2 cents per gig — another $4,000. So their monthly cost jumped to $38,000. A 58 percent increase. Luna: That’s brutal. And it’s not just about the money — it’s about the unpredictability. If you’re an engineering team that thought multi-cloud would save you money, this completely changes the math. Lucas: It does. And the worst part is, many teams don’t even know they’re triggering this fee. The routing decision is often buried in a load balancer config or a DNS resolution rule. One engineer sets up a health check that routes traffic through a third cloud, and suddenly you’re getting a six-figure surprise on your monthly bill. Luna: So what should teams do? Is there a way to avoid it? Lucas: The most straightforward fix is to avoid routing traffic through multiple clouds before it reaches the user. If you’re using AWS for compute and GCP for analytics, you can have the analytics results sent back to AWS and then served from there. That way, traffic only egresses from one cloud to the user. Luna: But doesn’t that add latency? You’re sending analytics results back to AWS, then out to the user. Lucas: It can add a few milliseconds, but for most applications, that’s negligible. And the cost savings are enormous. Alternatively, you can use a third-party content delivery network that sits outside the big three clouds — like Cloudflare or Fastly — and have your traffic egress from there. Those CDNs don’t have these routing fees. Luna: That’s interesting. So the cloud providers are essentially punishing you for using their networks as transit between clouds. Lucas: Precisely. They want you to either stay within their ecosystem — where inter-service traffic is often free — or use an intermediary that doesn’t compete with them. It’s a form of vendor lock-in that’s more subtle than the old data egress fees, but arguably more effective because it’s harder to detect. Luna: I’ve heard some FinOps teams are now adding a new metric to their dashboards: the 'multi-cloud routing ratio' — the percentage of traffic that touches more than one cloud before reaching the user. Lucas: That’s exactly the right approach. You need to monitor it, set alerts when it spikes, and make sure your DevOps team knows the cost implications. One company I spoke with — a large e-commerce platform — reduced their routing ratio from 35 percent to 2 percent in three months and saved $1.2 million annually. Luna: So it’s not just a cost issue — it’s a design principle. If you’re building a multi-cloud architecture today, you have to explicitly design for egress routing efficiency. Lucas: And that’s a shift from even two years ago, when the conversation was all about data egress volume. Now it’s about the path the data takes. The cloud providers are getting more granular with their pricing models, and enterprises need to adapt. Luna: You know, it reminds me of how airlines started charging for checked bags, then for carry-ons, then for seat selection. It’s unbundling — but in this case, the unbundling is happening on the routing layer. Lucas: That’s a great analogy. And just like with airlines, the playbook is the same: the fees are small enough to seem unimportant on a per-transaction basis, but they add up to huge numbers at scale. The only defense is visibility and intentional design. Luna: Speaking of visibility — you mentioned that many teams don’t know they’re triggering these fees. How would you recommend an engineering leader get a handle on this? Lucas: First, audit your current egress paths. Most cloud providers have cost and usage reports that show traffic by destination IP. If you see traffic going to IP ranges owned by another cloud provider before hitting the internet, that’s a red flag. Second, implement tagging for all egress traffic. AWS allows you to tag your VPC endpoints and route tables, so you can attribute costs to specific teams or applications. Luna: And I’d add — make sure your contract renegotiation team is aware of these fees. They might be able to negotiate a waiver or a discount if you commit to a certain volume of traffic that doesn’t trigger the routing fee. Lucas: Good point. Some of these fees are negotiable for large enterprise customers, especially if you’re willing to sign a longer-term commitment. The cloud providers are making these fees standard in their published price lists, but the actual contract can have carve-outs. Luna: So the lesson is: don’t assume multi-cloud routing is free. It’s a line item now, and it’s going to become more common. Lucas: Exactly. And if you’re building a new application today, I’d strongly consider whether you really need multi-cloud for the data path. Maybe keep your compute and storage within one cloud, and use multi-cloud only for specialized services that don’t involve moving traffic through multiple clouds in real time. Luna: That’s a sensible rule of thumb. And it ties back to something we’ve talked about before — the idea that cloud contracts are becoming more like utility contracts, with all these fine print charges for routing, latency, and usage patterns. Lucas: Right. And you know, we deliberately don’t run ads on these episodes. We think the information should stand on its own. If you find these deep dives useful for what you’re building or running, and you want to support that choice, the link is buy me a coffee dot com slash fexingo. No pressure, just an option. Luna: Yeah, we believe in keeping this ad-free so we can focus on the details without distractions. And listener support is what makes that possible. Lucas: So, back to those routing decisions — one more thing I want to flag: the cloud providers are also starting to charge for traffic that goes through their private backbone instead of the public internet, even if it stays within the same cloud. But that’s a topic for another episode. Luna: We’ll save that one. For now, the takeaway is: check your egress routes, measure your multi-cloud routing ratio, and renegotiate your contracts before the next billing cycle hits. Lucas: And if you’re a DevOps engineer listening, go look at your load balancer config right now. You might find a routing rule that’s costing you way more than you think.