A public-sector customer requires that their data stay within the EU, including support interactions. Your cloud provider offers an EU data boundary and your own support rota is global. What does meeting this actually require, and what does it cost?

What is gained

A credible residency claim, which for some customers is the difference between a signature and no deal. It is worth being precise about what the claim covers, because the customer's question is usually broader than the provider's commitment.

Microsoft's EU Data Boundary is the useful documented reference for the shape of the problem, because it was delivered in phases that map onto the categories an architect must handle: customer data from January 2023, pseudonymised personal data from January 2024, and professional services data — support case notes and customer-supplied logs — completed in February 2025, with documented exceptions where a global security incident requires data to leave. That three-phase sequence is itself the lesson: the easy category is the application's primary data, and the hard categories are telemetry and the things humans write about customers while helping them.

What is paid

• Support becomes a staffing problem, not an architecture problem. A follow-the-sun rota means an engineer outside the EU reading a ticket, and reading is access. The options are an EU-only rota for these customers (expensive, and hard to staff for a 24-hour service), or a support model where non-EU engineers can act without reading customer data — which means remote-controlled tooling, redacted diagnostics and an auditable break-glass path with EU approval.
• Telemetry is the biggest hidden surface. Logs, traces, crash dumps, session replays, error aggregators and product analytics all carry customer content, and each is usually a separate vendor with its own region settings. Expect this to be the longest part of the programme.
• Every third-party integration inherits the constraint, including the ones with no personal data in their marketing material.
• A separate deployment, or at least a separate data plane, with its own release path. Two planes means two of everything operationally, and the smaller one gets less testing.
• Key custody questions. Residency and sovereignty are different claims: where the bytes sit, versus who can be compelled to produce them. Customer-managed keys in an external store address part of the second question and not all of it.

When the cost becomes visible

At the first incident on the sovereign plane, when the engineer who knows the system is not allowed to look at the data, and at the first penetration test or audit that asks for a data-flow diagram including support and telemetry. The sales commitment is made in a month and the telemetry work takes three quarters.

How to keep the option to reverse

Make residency a property of configuration rather than of code: region as a deployment parameter, every third-party destination resolved from configuration, and no hardcoded endpoints. Then a second boundary — a different jurisdiction, a different customer — is a deployment rather than a rewrite. Treat the first sovereign customer as the template, and write the data-flow inventory even if only one customer needs it, because that inventory is the asset that makes the second one cheap.

When this is the wrong answer

If the requirement is actually "we need assurance about who can access our data", a sovereign deployment may be an expensive answer to a question that encryption, customer-managed keys and an access-transparency log answer better. Ask what the customer is protecting against — a foreign legal order, a cloud provider's staff, or an auditor's checklist — because the three have different cheapest answers, and residency is only the right one for the first. And for a small product with a handful of such customers, the honest commercial answer is sometimes to decline the requirement rather than to run two planes.