Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Cloud Region Data Residency Realities in 2026
Transcript
- Lucas: So, June 2026. There are now over a hundred cloud regions across AWS, Azure, and GCP combined. Every year, the hyperscalers open more—this year it's been Hyderabad, Milan, and a second region in Mexico City. Luna: More regions, more choices. But also more complexity when it comes to where data actually lives. Lucas: Exactly. And the complexity isn't just technical—it's legal. Data residency laws are proliferating faster than the regions themselves. India's data localization rules, Brazil's LGPD, China's Cybersecurity Law, and of course GDPR in Europe. Each one says: certain data must stay within the country's borders. Luna: Which means an enterprise with customers in all those places can't just pick one region and call it a day. Lucas: Right. So let's talk about a real example. A global industrial manufacturer—let's call them ManuCorp—they operate in thirty countries, have factories in India, Brazil, Germany, and the US. They decided to move their ERP and customer data to the cloud. The plan was to simplify IT. But then the compliance teams got involved. Luna: I bet. The legal requirements don't care about your tidy single-region architecture. Lucas: Not at all. For ManuCorp, the first constraint came from India. India's revised data localization rules, which went fully into effect last year, require that 'critical personal data'—that includes employee and customer data—be processed and stored only in India. Export is allowed only under strict conditions. Luna: So they couldn't just spin up a database in Singapore and call it South Asia coverage. Lucas: Nope. They needed an Indian region. Azure has two in India, AWS has two, GCP has one. ManuCorp already used AWS, so they went with Mumbai. But then GDPR said: personal data of EU residents must stay in the EU or a country with adequate protection. So they needed a Frankfurt or Ireland region. Luna: And Brazil's LGPD effectively requires data to stay in Brazil for certain categories. So that's a São Paulo region. Lucas: Exactly. Suddenly ManuCorp is looking at three mandatory regions—Mumbai, Frankfurt, and São Paulo—plus their US headquarters data in Virginia. Four regions minimum. And the data can't just sit in silos. Their supply chain application needs to query inventory levels across all factories in near real time. Luna: So now you've got cross-region latency. Mumbai to Frankfurt is what, a hundred and fifty milliseconds round trip? Lucas: About that. And Mumbai to São Paulo is even worse—two hundred and fifty milliseconds plus. For an ERP transaction, that's noticeable. The application was designed with the assumption that all data was in one data center. Suddenly, every query that touches multiple regions has to deal with that latency. Luna: I've heard of teams solving this with read replicas in each region and local writes, then async replication. But that gets expensive fast. Lucas: That's exactly what ManuCorp did. They used Aurora Global Database on AWS—one primary in Virginia, read replicas in Mumbai, Frankfurt, and São Paulo. Writes go to Virginia, then replicate asynchronously to the others. Reads are local, so latency is fine for queries. But the replication lag can be up to a second. And storage costs multiply because you're paying for full copies in four regions. Luna: A second of lag might be okay for a dashboard, but for inventory updates during a production run, that could cause problems. Lucas: Right. And here's the kicker: some of ManuCorp's data—specifically employee HR data in India—cannot leave the country at all. Not even for replication. So that data had to stay in a separate database in Mumbai only, with no sync to Virginia. That broke their global HR analytics tool, which expected a single view of all employees. Luna: Oof. So they had to redesign the analytics layer to query multiple sources and stitch results together. That's a whole project in itself. Lucas: Exactly. And the networking costs—data transfer between regions is not cheap. AWS charges roughly two to four cents per gigabyte for cross-region transfer. ManuCorp's replication traffic alone added about fifty thousand dollars a month to their cloud bill. Luna: That's real money. And it's a direct consequence of compliance, not of application need. Lucas: Which brings us to a bigger point: data residency isn't just a checkbox. It reshapes your architecture, your costs, and your operational complexity. And it's only getting more fragmented. Thailand just proposed a data localization law. Turkey is enforcing its own. Even US states are starting to talk about it—California's privacy laws already have data portability requirements. Luna: Honestly, if this episode was worth a coffee to you, that's the link—buy me a coffee dot com slash fexingo. It helps us keep these conversations ad-free and focused on what matters for builders and operators. Lucas: Yeah, and we really appreciate it. Every little bit helps us spend more time digging into stories like ManuCorp's. Now, the other angle here is that the hyperscalers are starting to offer services specifically to help with this. Luna: You mean like AWS' DataZone or Azure Purview? Lucas: Yes. AWS DataZone lets you catalog and govern data across regions, and you can tag data with residency requirements. Azure Purview has similar capabilities. But these tools are still immature. ManuCorp tried DataZone and found that enforcing residency policies at the data-catalog level required a lot of custom rules and manual tagging. Luna: So the automation isn't there yet. Enterprises are still doing a lot of this by hand or with homegrown scripts. Lucas: Right. And the other challenge is that cloud providers don't guarantee data locality at the application layer. They guarantee it at the storage layer—your S3 bucket is in a specific region. But if your application code accidentally sends data to a different region—say, a logging service that aggregates logs to us-east-1—you've violated compliance. Luna: So it's not just where you store it, it's where your code runs and where data flows through. That's a much harder thing to control. Lucas: Exactly. ManuCorp had to audit all their Lambda functions and API calls to ensure no data was inadvertently leaving the region. They found several cases where a debugging endpoint was sending payloads to a central logging bucket in Virginia. That was a compliance risk they hadn't considered. Luna: And fixing that meant either routing logs locally or stripping sensitive data before sending. More engineering work. Lucas: Yeah. So what's the takeaway? First, if you're a multinational enterprise, assume you'll need at least three to five regions for compliance reasons alone—not performance. Second, plan for your data architecture to be federated from day one. A single-region design will break when legal says you can't put everything in one place. Luna: And third, budget for the networking and replication costs. They're not trivial. Lucas: Right. One estimate I saw from an enterprise architecture firm: for a company with operations in ten countries, compliance-driven multi-region architecture adds twenty to thirty percent to the total cloud bill compared to a two-region disaster recovery setup. Luna: That's significant. But it's the cost of doing business globally in 2026. Lucas: And it's not going away. If anything, more countries are moving toward data localization, not away from it. So the smart move is to build for that reality now rather than retrofitting later.