Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / The Multi-Cloud Tax and How Enterprises Actually Manage It
Transcript
- Lucas: So there is a statistic that keeps rattling around in my head. HashiCorp released their State of Cloud Strategy survey last fall — 2025 — and it found that 87 percent of enterprises are now running workloads on at least two public clouds. Luna: Yeah, I remember that number. And it feels like every conference keynote for the last three years has been screaming 'multi-cloud is inevitable.' Lucas: Inevitable, sure. But the same survey found that only 13 percent of those organizations have a unified governance plan across those clouds. That gap — 87 percent adoption, 13 percent governance — that is the multi-cloud tax in a nutshell. Luna: Let's define that term. When you say 'multi-cloud tax,' you mean the hidden cost of operating across multiple providers, right? Not just the raw compute bill. Lucas: Exactly. It's the overhead you don't see on the invoice line. Duplicated tooling — you need monitoring for AWS CloudWatch and Azure Monitor and GCP Cloud Operations. Separate identity systems. Compliance teams have to audit three different consoles. And then there's the egress. Luna: Egress is the killer. Moving data out of one cloud to another, or to the internet. AWS charges nine cents per gigabyte for the first ten terabytes a month transferred out. Azure is about eight cents. GCP is similar, around ten to twelve cents depending on the destination. Lucas: And that doesn't sound like much until you have a data pipeline that shuffles fifty terabytes between clouds every day. Suddenly you're looking at four thousand dollars a day just in transfer fees. Over a year, that's real money. Luna: Which brings up the question: why do companies do it? The pitch for multi-cloud is usually 'avoid lock-in' or 'best of breed.' Pick the best AI service from Google, the best serverless from AWS, the best Active Directory integration from Azure. Lucas: Right. And there are valid use cases. A lot of enterprises have Azure because they have a Microsoft E3 or E5 license, but then their data science team loves SageMaker on AWS, so they run their ML training there. That's two clouds out of necessity, not ideology. Luna: But Gartner published a report in 2024 that really challenged the cost-saving narrative. They found 70 percent of multi-cloud adoptions fail to deliver on expected cost savings. The complexity ends up eating the margin. Lucas: I remember that note. The analysts basically said if you're splitting identical workloads across two clouds just to get leverage in pricing negotiations, you're probably losing money. The operational overhead outweighs the discount. Luna: So what does a smart multi-cloud strategy look like? Because I don't think anyone is arguing that single-cloud is always the answer either. Lucas: No, and I think the smartest approach I've seen is the 'primary plus specialized' model. You pick one cloud as your core compute foundation — 70 to 80 percent of your workloads — and then you use a second cloud only for services that the primary can't match. Luna: Give me an example. Who's doing this well? Lucas: DoorDash is a good one. They're mostly on AWS, but for certain data analytics workloads they use Google BigQuery. They built an internal abstraction layer called the 'Data Platform' that lets their teams write queries and not care which engine is running behind the scenes. Luna: So they're not avoiding lock-in per se. They're managing it by creating a unified interface. Which is smart, because the lock-in isn't the cloud provider as much as it is the team's expertise. Lucas: Exactly. The hardest lock-in to break is your engineers' familiarity with a specific console, a specific IaC tool, a specific logging format. That's where the real switching cost is. Luna: Another example I like is Intuit. They run TurboTax and QuickBooks on a mix of AWS and their own private cloud. But they famously wrote a tool called 'CloudPath' that abstracts away the provider-specific APIs. Lucas: Yeah, CloudPath is like a router for cloud services. You say 'I need a queue,' and it picks whether to use AWS SQS or something else based on cost and latency at that moment. That level of abstraction is hard to build, but if you can pull it off, you really do get flexibility. Luna: But I'd argue that most enterprises don't have the engineering bench strength to build a CloudPath or a Data Platform. They're looking at SaaS tools like HashiCorp Terraform and Consul to manage multi-cloud. Lucas: And that works — to a point. Terraform gives you infrastructure as code that can target any provider. Consul handles service discovery across clouds. But you're still paying for those tools, and you still need a team that knows how to use them. Luna: So what's the concrete takeaway for someone listening who's a VP of Engineering or a CTO? They're probably already multi-cloud. How do they stop bleeding cost? Lucas: I would say three things. One: measure your egress. Put a dashboard up that shows exactly how much data is leaving each cloud, and flag any cross-cloud traffic that isn't a genuine business requirement. Luna: Number two? Lucas: Two: pick one cloud as your 'default' for general purpose compute and databases. Use the second or third cloud only for workloads that genuinely benefit from a unique service. Don't replicate identical architectures. Luna: And three? Lucas: Three: invest in a thin abstraction layer for the top five things you do across clouds — compute, storage, messaging, identity, and monitoring. Even a simple wrapper library can save months of rework if you ever decide to shift weight. Luna: I think the identity piece is the one most people underestimate. You have to manage user roles in AWS IAM, Azure AD, and GCP Cloud IAM. That's three different naming conventions, three different policy languages. Lucas: And those policies don't talk to each other. So you end up with security gaps or you over-provision permissions just to get things working. The multi-cloud tax in security is real, and it's expensive. Luna: Alright, so let's look forward a bit. It's May 2026. Are the cloud providers making this easier, or harder? I saw AWS launched a new feature in January called 'Cloud WAN' that's supposed to simplify connecting on-prem and multi-cloud networks. Lucas: They are, but each provider's solution is designed to make their own cloud the center of gravity. Cloud WAN is great if you're aws centric and you want to connect a branch office or an Azure spoke. But it's not a neutral tool. Luna: And that's the rub. The cloud providers are happy to talk about multi-cloud in keynotes, but they're all building moats. The egress fees aren't going away. The interoperability is never seamless. Lucas: No, and I don't expect it to change. The business model depends on stickiness. So the burden falls on the enterprise to be disciplined about where they put workloads and why. The ones that do it well are the ones that treat cloud provider as a procurement decision, not a religion. Luna: One last stat I want to bring up. In the same HashiCorp survey, only 8 percent of respondents said they were 'very confident' they understood their total cloud costs across all providers. That's terrifying. If you don't know what you're spending, you can't optimize it. Lucas: Right. And I think that's the episode in a nutshell. Multi-cloud is here, it's messy, and the tax is real. But with deliberate architecture, measured egress, and a clear primary-seconday strategy, you can pay less of it. Luna: And maybe the most important thing is to know what you're actually spending. Turn on those cost explorer tools in each cloud, get a third-party dashboard if you can, and look at it weekly. Lucas: Weekly might be aggressive for some, but at least monthly. Because the cloud tax compounds quietly. Alright, that's the view from here. For The Cloud Business Podcast with Fexingo, I'm Lucas. Luna: And I'm Luna. We'll be back with another angle on enterprise infrastructure next week.