The re:Invent 2025 Speech We All Heard vs. The Bill We’ll Actually Pay
If you watched Andy Jassy’s keynote at AWS re:Invent 2025, you probably heard a lot about price cuts and competitive positioning. Amazon announced further S3 pricing reductions and rolled out expanded zero-egress agreements with select CDN partners. The message was clear: we’re listening to competitive pressure from Google Cloud and Azure, and we’re doing something about it. The applause was genuine. The relief was palpable.
Here’s the thing nobody wants to admit in a keynote: when you’re running anything resembling a real multi-cloud strategy, those headline wins barely dent your actual egress costs. I’ve been in enough war rooms to know the difference between marketing narratives and what your CFO sees at month-end close. The pricing reductions matter for certain workloads on specific services. But for enterprises actually moving data between cloud providers at scale, the story remains stubbornly unchanged.
This is where the rubber meets the road. And the road is expensive.
The Egress Tax Nobody Negotiates Their Way Out Of
According to Cloudflare’s 2025 Bandwidth Alliance research, enterprises moving significant volumes of data between major cloud providers still face average egress fees in the range of $0.08 to $0.09 per GB for high-volume transfers that fall outside alliance agreements. Let that number sit for a moment. If you’re moving just 10 TB between clouds monthly, you’re looking at roughly $800 to $900 before you even think about ingress costs, storage duplication, or the operational overhead of managing the transfer itself.
The Bandwidth Alliance partnerships help, sure. If you’re using Cloudflare, Fastly, or a handful of other approved partners, you might catch a break. But here’s where it gets real: most enterprises don’t have the traffic patterns that fit neatly into these alliance frameworks. Your workloads are asymmetrical. Your growth is unpredictable. Your compliance requirements push data to specific regions that aren’t covered by the preferred partner list.
I’ve watched teams celebrate landing a 15 percent discount on egress through negotiation, then watch their bill spike 40 percent the following quarter because they launched a new data pipeline nobody had accounted for in the negotiation. The algebra never works the way you hope.
The Maturity Gap Nobody’s Talking About
According to the Flexera 2026 State of the Cloud Report, 89 percent of enterprises have adopted some form of multi-cloud strategy. That number should make you feel less lonely. But then Flexera measured something more useful: only 28 percent of those enterprises report having mature cost governance tools deployed across all their providers. Let that asymmetry sink in.
89 percent minus 28 percent equals organizations flying blind. They have multi-cloud workloads, they have multi-cloud bills, but they don’t have the observability infrastructure to understand which workloads are costing them what, across which providers, in which regions. Gartner’s 2025 Cloud Cost Optimization report estimated that 35 percent of enterprise cloud spend is wasted, with multi-cloud networking costs taking up an increasing slice of that pie.
Egress fees are often the easiest place to hide this waste. They’re commoditized and opaque. They don’t show up in your per-VM cost tracking. They live in a separate line item that most teams never correlate against the business value they generated. By the time you notice it’s a problem, you’ve already shipped the architecture that made it inevitable.
What Google Cloud’s New Cross-Cloud Network Actually Means (and Doesn’t)
Google Cloud announced the Cross-Cloud Network at Google Cloud Next 2025, framing it as a solution to exactly this problem. Simplified inter-cloud connectivity, they promised. Unified networking across your multi-cloud estate. It sounds like exactly what we’ve been waiting for.
Then you read the fine print. The solution requires workloads to run on supported regions within specific Google Cloud proximity, which constrains practical adoption immediately. If your compliance posture requires data residency in regions where Google Cloud doesn’t offer this integration, you’re back where you started. If your AWS workloads are locked into us-east-1 for legacy reasons and your Google workloads need to be in europe-west1, the cross-cloud network becomes a nice feature you can’t actually use.
This isn’t a criticism of Google’s engineering. It’s a recognition that solving the multi-cloud cost and complexity problem at the networking layer requires architectural flexibility that most enterprises simply don’t have. We’re all constrained by history, compliance requirements, and the sunk cost of existing infrastructure.
The Real Lever: Knowing What You’re Actually Moving
If you want to actually move the needle on multi-cloud costs, the solution isn’t waiting for the next re:Invent keynote or the next Google Cloud announcement. It’s deliberately unglamorous: you need comprehensive visibility into what data is moving where, why, and at what cost. You need the kind of observability that lets you correlate egress charges against actual business outcomes.
Start by mapping your data flows. Not your service dependencies, not your architectural diagrams. Your actual data movement. Where is data leaving AWS, when, and how much is it costing you? Same question for Google Cloud, Azure, and wherever else you’re running workloads. You’d be surprised how many teams can’t answer this question with confidence.
Then stress-test your CDN and alliance partnerships. If you’re not sitting at the table understanding exactly which transfers fall inside versus outside your negotiated terms, you’re leaving money on the table. Call your account teams. Ask hard questions. The answer might be that you need to reshuffle your architecture, consolidate providers in specific regions, or invest in different tools. But at least you’ll be making that decision from actual data, not assumption.
The AWS data transfer pricing breakdown is public, and so are the pricing models for other major clouds. The variable isn’t the published prices. It’s that most organizations don’t have the instrumentation to connect their billing data to their actual workloads.
The real cost of multi-cloud in 2026 isn’t the egress fees themselves. It’s the absence of visibility that makes you unable to optimize them away. That’s a solvable problem. It just requires patience, systematic thinking, and the willingness to look at data that nobody wants to present at an all-hands meeting. Which, if you’re reading this, is probably familiar territory already.
If you’ve tackled this in your own infrastructure, or found clever ways to navigate the egress tax that actually worked, I’d genuinely like to hear about it. Drop a note in the comments or reach out. The gap between how this stuff is presented and how it actually works in production is where the interesting conversations happen.
