Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / The CLOUD BRIDGE: How Enterprises Are Migrating Data for AI Workloads
Transcript
- Lucas: There's a term that's been floating around infrastructure circles for a while — 'data gravity' — and it's finally becoming the central problem for enterprises that are serious about AI. Luna: Data gravity — the idea that the bigger your data gets, the harder it is to move, and the more services tend to cluster around it. Lucas: Exactly. And what we're seeing right now is that companies that spent the last five years carefully distributing data across multiple clouds are suddenly facing a hard choice: they need to move petabytes of data to wherever their AI training is happening. And that migration is neither fast nor cheap. Luna: So give me a concrete example. Who's actually doing this and how painful was it? Lucas: I've been tracking a case from a large retailer — think top 50 in the Fortune 500 — that had been running its data warehouse on a combination of on-premises Hadoop clusters and Amazon S3. When they decided to build a large language model for supply chain forecasting, they chose Google Cloud because of its Tensor Processing Unit availability and Vertex AI integration. Luna: Right, the TPUs are a differentiator. But then they had to actually get their data to Google Cloud. Lucas: Exactly. We're talking about roughly 3 petabytes of structured and semi-structured data, plus another half petabyte of logs. They had to move it over the network because shipping physical disks was too slow for their timeline. Total egress fees from AWS: about one point two million dollars. Plus the engineering time to re-architect their pipelines for Google Cloud Storage and BigQuery. Luna: One point two million in egress alone. And that doesn't include the compute cost to run the migration tools, or the opportunity cost of having a data engineering team tied up for, what, months? Lucas: Fourteen weeks from start to production. The project was considered a success, but the CFO was not thrilled about the line item. And this is becoming a pattern: enterprises are making ai driven cloud choices that override their previous multi-cloud strategies. Luna: So is the era of 'cloud agnosticism' ending? Because a lot of companies built their architectures to avoid lock-in, but if AI workloads force you to where the best hardware is, that lock-in is real. Lucas: I think the practical reality is that most enterprises will end up with a primary cloud for AI and secondary clouds for everything else. The question is whether the big three — AWS, Azure, Google Cloud — are making it easier to move data between them, or harder. Luna: And that's where the networking products come in. Google has their Cross-Cloud Network, AWS has Direct Connect, Azure has ExpressRoute. But those are point to point, not a mesh. Lucas: Right. Google's Cross-Cloud Network is interesting because it's explicitly designed to help customers move data into Google Cloud from other providers. They offer reduced egress fees for certain large transfers, and they've been building out dedicated interconnects with AWS and Azure data centers. But it's still a one-way street — the incentives are structured to make it cheap to come in, not to leave. Luna: Which is exactly what you'd expect. Every cloud provider wants to be the gravity well. And for the customer, the cost of moving data out is almost always higher than the cost of moving it in. Lucas: That's the lock-in mechanism. And it's not new, but AI is amplifying it because the data sets are so much larger. I spoke with a network architect at a financial services firm who told me they're now budgeting for a 'migration allowance' of three to five million dollars per year just for data movement between clouds. Luna: That's a whole new line item in the cloud budget. 'Data mobility expense.' Lucas: Exactly. And if these conversations about real infrastructure decisions are useful for what you're building or running, it's worth mentioning that this podcast stays ad-free thanks to listeners who choose to support it. If you find value in episodes like this, you can buy me a coffee at buy me a coffee dot com slash fexingo — all lowercase. It helps us keep digging into the details that matter for operators. Luna: Yeah, and it really does make a difference. Keeps the show independent and focused on the engineering and business trade-offs, not on sponsor talking points. Lucas: So back to that financial services firm — they're using a combination of AWS for general compute and Google Cloud for AI training, and they've set up a dedicated 10-gigabit link between the two using AWS Direct Connect and Google's Partner Interconnect. The latency is under two milliseconds, but the bandwidth still bottlenecks when they're moving daily training data. Luna: So the network becomes the constraint. And that's pushing people toward architectures where they replicate data across clouds rather than moving it each time. Lucas: That's the counter-trend I'm seeing: some enterprises are saying, 'Fine, we'll store our core data sets in three places.' But that triples storage costs. For a petabyte-scale data lake, that's significant. Luna: What about the mid-market companies that don't have Fortune 500 budgets? They can't afford a dedicated interconnect or a multi million dollar migration. Lucas: They're often forced into a single-cloud strategy from the start, which is why we're seeing a lot of mid-market AI adoption happen entirely within one provider's ecosystem. They pick Azure because of the OpenAI relationship, or Google Cloud because of the TPUs, and they never try to spread data across multiple clouds. The migration problem is deferred until they decide to switch. Luna: Which is a bet on that provider's future capabilities. If you go all-in on Azure today, you're hoping that in three years they still have the best AI hardware. Lucas: That's the risk. And the major clouds know it, which is why they're all investing heavily in custom silicon. Google's TPU v6 is supposed to be available in preview by the end of this year. AWS has Trainium and Inferentia. Azure has the Maia chip. Each is trying to be the best place to run AI, not just the best place to store data. Luna: So data gravity is shifting from storage to compute. The data follows the compute, not the other way around. Lucas: That's a great way to put it. For years, the mantra was 'bring compute to the data.' Now, with AI, it's becoming 'bring data to the compute' — because the compute is specialized and scarce. And that reversal has huge implications for network architecture, data governance, and cost management. Luna: And for compliance too. If your data has to move across regions or even countries to reach the AI hardware, you run into data sovereignty issues. I've heard of European companies struggling with that. Lucas: That's the next layer. Google, for example, has TPU clusters in us-central1 and europe-west4, but not in asia-northeast1. So a Japanese company that wants to use TPUs has to either accept the latency of running in Europe or the US, or find a different hardware provider. Some are turning to AWS Trainium in Asia-Pacific regions, but then they have to rebuild their model pipelines. Luna: Which brings us back to lock-in. The more specialized the hardware, the less portable the workload. Lucas: And that's why I think the next big battleground in cloud is not just AI chips — it's the network and data mobility layer between them. If a provider can make it cheap and easy to move data in, and expensive to move it out, they'll win the AI workload. And the data gravity will just keep pulling everything into their orbit. Luna: So for the enterprise customer, the smart move might be to pick one AI cloud and accept the lock-in, but negotiate hard on egress fees and commit to a multi-year contract with clear data mobility guarantees. Lucas: That's exactly what the more sophisticated procurement teams are doing. They're writing data portability clauses into their contracts — things like 'if we decide to leave, you will provide free egress for up to six months.' Not every provider agrees, but enough do that it's becoming a standard negotiation point. Luna: And that's a sign that the market is maturing. Customers are learning from the first wave of cloud migration and applying those lessons to the AI migration. Lucas: Right. The first wave was about moving from on-prem to cloud. The second wave is about moving between clouds. And the third wave, which we're in the middle of right now, is about moving data to the best AI compute. The winners will be the providers that make that move as frictionless as possible — not just in terms of latency, but in terms of cost, compliance, and engineering effort. Luna: And the losers will be the ones that try to trap their customers with punitive egress fees and poor interconnect options. Lucas: Exactly. So if you're an infrastructure operator listening, the takeaway is: audit your data gravity now. Figure out where your largest data sets live, where your AI workloads will run, and start planning the migration path — even if you're not moving yet. The cost of moving later is only going to go up as data volumes grow. Luna: Good advice. And maybe the most practical thing we can say: don't wait until the CFO sees the egress bill to start thinking about it. Lucas: Yeah. Plan ahead, negotiate early, and always assume the data will need to move at some point. The cloud is not a destination — it's a layer. And the data is going to find its gravity well one way or another.