Self-Hosting vs Cloud Providers EU Sovereignty

Part 1 unpacked the fear and the real drivers behind EU sovereignty concerns. Now let's talk about what to actually do about it. If you're uncomfortable with US cloud providers, what are your options? And more importantly, what are the trade-offs that come with each choice?

Here's what I've learned from working with organizations that have taken different paths: there's no pure sovereignty solution. Every option trades something off—cost, performance, control, or operational complexity. The art is understanding which trade-offs matter for your specific situation and which are just theater.

Option 1: Back to Self-Hosting (The Classic Model)

The purest form of sovereignty is running your own data center. Your servers, your facility, your staff, your data. No cloud provider involved. No US company. No borders crossed.

On paper, this sounds great. In practice, it's a fundamentally different business model with costs and responsibilities that often surprise organizations accustomed to cloud thinking.

The Real Cost of Self-Hosting

Let's be concrete. Say you want to self-host a web application and database with reasonable redundancy. Here's what that involves:

  • Capital expenditure: Secure facility with power, cooling, physical security. Equipment: servers, storage, networking, firewalls. Expect €100k-500k upfront depending on scale.
  • Operational costs: Staff to maintain, patch, monitor, and operate infrastructure. At least one full-time ops engineer, ideally two. €60k-100k per year in salary, plus benefits.
  • Redundancy and failover: You need multiple sites for true resilience (never host everything in one facility). That doubles or triples costs.
  • Compliance and auditing: ISO 27001 certification, penetration testing, audit trails. €20k-50k per year.
  • Scaling challenges: As you grow, you provision more hardware. That's capital expenditure plus procurement lead times (weeks to months).

Compare this to Azure: €500-2000/month for the equivalent infrastructure, with auto-scaling, built-in redundancy across data centers, and compliance certifications already in place.

The Math: For most organizations, self-hosting costs 5-10x more than cloud, and that's optimistic. The trade-off is sovereignty: you control everything, but you also own all the risk and operational burden.

When Self-Hosting Makes Sense

Self-hosting isn't obsolete; it makes sense in specific scenarios:

  • Critical infrastructure operators - Required by law or policy to control their own infrastructure. No choice. They self-host.
  • High-value IP or trade secrets - Organizations handling irreplaceable intellectual property or strategic materials. The cost of compromise is so high that the sovereignty overhead is justified.
  • Air-gapped systems - Systems that can't connect to the internet or public cloud by design. Military, certain government agencies, some financial institutions. They self-host because they have to.
  • Regulatory mandate - Some countries or sectors legally require on-premises hosting. France has a "Cloud pour l'Etat" (Cloud for the State) program that incentivizes government to use local data centers.

Notice something? These aren't cost-driven decisions. They're driven by sovereignty requirements that outweigh cost. If the decision is purely cost-based, cloud wins every time.

Option 2: The New Wave—EU-Based Cloud Providers

This is where Europe is actually investing now. There are several initiatives trying to build European cloud infrastructure that keeps data within EU borders:

  • Gaia-X: An open-source, federated cloud infrastructure initiative. Partners include Siemens, Deutsche Telekom, SAP. Goal: create European cloud sovereignty while staying vendor-flexible.
  • OVHcloud: French cloud provider with strong focus on GDPR compliance and data residency.
  • Ionos: German cloud provider with data centers in Germany.
  • Data4: French data center operator, working on cloud sovereignty initiatives.
  • UpCloud: Finnish cloud provider with ISO 27001 certification and explicit EU Sovereign Cloud offering. 15 data centers across 12 countries including Helsinki (Finland), Stavanger (Norway), Stockholm (Sweden), and Copenhagen (Denmark). Zero egress costs, 99.999% SLA.
  • Binero: Swedish cloud provider with data stored exclusively in Sweden, ISO 27001 certified, GDPR compliant. Public cloud, managed services, and infrastructure offerings.
  • Elastx: Swedish cloud infrastructure provider focusing on OpenStack-based IaaS with Swedish data centers for EU sovereignty.

These providers offer a middle ground: cloud infrastructure (no self-hosting burden) with European control and data residency guarantees.

The Trade-Off: Feature Parity vs. Cost

Here's the uncomfortable truth: European cloud providers don't have the feature parity of Azure, Google Cloud, or AWS. They offer infrastructure—compute, storage, networking. What they don't offer (yet) are the higher-level services:

  • Advanced AI and machine learning platforms
  • Integrated analytics and data warehousing at scale
  • Containerization and Kubernetes simplicity
  • The breadth of managed services (CDNs, DNS, security, identity)

If you need basic compute and storage, European providers work fine. If you're building something that depends on advanced cloud services, you're likely going to end up assembling components yourself or accepting some dependency on US-based providers.

Provider Jurisdiction Best For Gaps vs. US Clouds Cost vs. Azure/AWS
OVHcloud France French/EU companies needing GDPR compliance, data residency Limited AI/ML, fewer managed services, smaller ecosystem Similar or slightly higher
Ionos Germany German companies, familiar with German datacenter operators Limited scale, fewer advanced services Similar pricing
Gaia-X EU (federated) Organizations wanting vendor flexibility and European control Still building-out, less mature than established clouds Competitive, varies by provider
Azure (EU data residency) US corporation, EU data centers Organizations needing US-level features but EU data residency None—full feature parity. Legal risk from US company Baseline for comparison
UpCloud Finland (multi-region Nordic) Nordic and EU organizations needing sovereign cloud with multi-country presence. Data centers in Finland, Norway, Sweden, Denmark Limited higher-level managed services; fewer geographic regions globally Competitive; no egress costs unlike major clouds
Binero Sweden Swedish/Scandinavian companies, sensitive workloads requiring Swedish data storage Limited managed services, smaller ecosystem than major clouds Similar or slightly higher than OVHcloud
Elastx Sweden Organizations wanting Swedish IaaS infrastructure with OpenStack focus Focused on infrastructure; limited higher-level managed services Competitive with other EU providers

Microsoft actually offers a hybrid solution here: Azure with data residency options. Your data stays in a German, French, or other EU data center, but you get full Azure features. The catch? It's a US company, so Schrems II still applies. But practically speaking, you get sovereignty-like control without self-hosting burden.

Option 3: The Hybrid Reality (What Most Organizations Actually Do)

Here's what happens in practice: Most intelligent organizations don't choose one option. They do something hybrid:

  • Non-sensitive workloads on US cloud: General web applications, testing environments, development infrastructure. Cost-effective, no sovereignty risk because there's nothing sensitive to protect.
  • Sensitive data in EU-based solutions or self-hosted: Personal data, financial records, healthcare information. Kept closer to home.
  • Critical infrastructure on-premises or EU-only: Anything that directly impacts operations. Redundancy and disaster recovery spread across EU providers to avoid single-vendor lock-in.

This approach acknowledges a key insight: not all data has the same sovereignty requirements. Your marketing website doesn't need sovereignty protections that a payment system does.

Practical Reality: The organizations making the most sensible decisions aren't trying to achieve pure sovereignty. They're doing risk-based data classification and applying the right controls to the right data. It's more nuanced than "all data must be in Europe."

The AI Agent Problem: Why Data Has to Move

Now here's where things get really complicated. In Part 1, I mentioned that AI agents change the game. Let me explain why.

When you use Azure Copilot or an AI-powered feature on your data, here's what happens behind the scenes:

  1. You ask the AI a question about your data (e.g., "Summarize these sales records")
  2. Your data gets sent to an AI processing system, which might be hosted in the US, Canada, or another region
  3. The AI model processes your data and returns a result
  4. The data may be cached, used for model training, or stored temporarily for debugging

This is where the sovereignty issue becomes acute. Your data, which was supposed to stay in Europe, left the region. It was processed outside your control. You lose visibility and control.

Why does this happen? Several reasons:

Reason 1: Model Inference Scale

Large language models and AI systems are computationally expensive. Building distributed AI inference in every region is extremely costly. Cloud providers centralize this in a few regions (US, mostly) to amortize the cost. Your data goes to where the compute is.

Reason 2: Model Training and Improvement

AI models improve by learning from data. If you use Copilot, Microsoft uses that interaction (your queries, the context, sometimes the actual data) to improve the model. This is disclosed in terms of service, but it means your data leaves the EU for model training and improvement.

Organizations understandably don't want this. If you're working with proprietary information, sending it to Microsoft's model training pipeline is unacceptable.

Reason 3: Logging and Debugging

When something fails or you report an issue, logs containing your data might be shipped to processing centers in the US for analysis. This is necessary for cloud providers to maintain service quality but creates a sovereignty problem.

The Uncomfortable Truth About Data Transfer

Here's what the sovereignty advocates often don't say: some data transfer across continents is actually necessary for modern cloud services. It's not just about surveillance; it's about the way cloud infrastructure actually works.

Why Data Transfer Is Necessary (And What Isn't)

Let me distinguish between transfers that are necessary and transfers that are convenience:

Transfer Type Necessary? Sovereignty Impact Alternative?
Backup to secondary region Practically necessary Minimal if secondary is within EU Multi-AZ within same region or EU-wide replication
AI model inference Necessary as currently architected Major—data leaves EU for processing On-premises AI models, but much less capable
Logging and telemetry Partially necessary Can be minimized with configuration Opt-out of telemetry, use on-premises logging
Push notifications for MFA Absolutely necessary Minimal data, but notification routing must cross borders Use SMS/TOTP instead, but less secure
Model training data Not necessary—it's a business decision Major—proprietary data used to improve models Opt-out of data usage, use non-generative solutions
Occasional compute burst to US regions Not necessary—it's cost optimization Major—data sent across continent for cheaper compute Enforce EU-only compute in contracts

Notice the distinction? Some transfers are technical requirements (backup, redundancy). Others are business optimization (model training, cost reduction). The privacy-conscious approach is: allow necessary technical transfers, block optimization transfers.

Key Insight: You can enforce contractual restrictions that prevent cloud providers from sending your data outside the EU unless it's technically necessary for service delivery. This is partially what newer EU contracts with cloud providers include. But it requires explicit negotiation and acceptance that some advanced services become unavailable.

A Real Example: Push Notifications for Multi-Factor Authentication

Here's a concrete example that illustrates the unavoidable infrastructure complexity. When you use Microsoft Authenticator with push-based approval in Microsoft Entra ID, here's what actually happens:

  1. User in Frankfurt logs into an application and chooses to approve via push notification
  2. Microsoft Entra ID (hosted in EU region) generates an authentication challenge
  3. A push notification request is sent to Apple Push Notification service (APNs) or Google Firebase Cloud Messaging (FCM)
  4. APNs/FCM (both US-based infrastructure) routes the notification to the user's phone
  5. User explicitly approves or denies the request on their device
  6. Response comes back through the same path

Critically, the user must explicitly request push-based approval. They choose this authentication method. But once they do, the notification routing path must go through US-based infrastructure. This is mandatory. Without US-based push services, modern app-based MFA simply doesn't work.

Why? Because Apple and Google control the only reliable, platform-scale push notification systems for iOS and Android. There is no European alternative. You could theoretically build EU-only push infrastructure, but it would require hundreds of millions of euros and would be inferior—only your users would exist on it. So organizations and users accept this cross-border transfer as the cost of having secure, modern authentication.

Other Unavoidable Infrastructure Transfers

Push notifications are just one example. Modern applications have many more:

  • DDoS Protection & Rate Limiting: Detecting distributed attacks requires global traffic analysis. Cloudflare, AWS Shield, and similar services analyze patterns across regions to identify coordinated attacks. You can't detect a DDoS from Frankfurt if the attack originates from thousands of sources globally.
  • AI Model APIs: Using OpenAI, Anthropic, or other AI services means sending queries to US infrastructure. Modern applications increasingly depend on these APIs for features like content generation, transcription, and analysis. The data must leave the EU to get results.
  • Container Image Pulling & Registry Scanning: Cloud-native applications pull Docker images from global registries (Docker Hub, ECR, etc.). Vulnerability scanning on those images happens globally. A developer in Frankfurt pulling an image triggers global security checks and caching.
  • Analytics & Observability: Modern apps use Datadog, New Relic, Elastic, or Splunk for monitoring. These require shipping logs, metrics, and traces to global processing centers where they're correlated and analyzed. EU-only analytics at scale is economically unfeasible.
  • Supply Chain Security Scanning: Tools like Snyk, Dependabot, and SBOM generators scan your dependencies for vulnerabilities. This scanning must cross borders to check against global vulnerability databases in real-time. Every time you deploy, vulnerability data is fetched globally.
  • Real-time Communication APIs: Building video conferencing, chat, or live features requires global infrastructure. Twilio, SendGrid, or similar services route your data through global networks for low-latency delivery. There's no European-only real-time communication network of equivalent scale.
  • CDNs for Dynamic Content: Modern CDNs (Cloudflare, Fastly, Akamai) don't just serve static files—they run serverless functions, handle real-time personalization, and cache dynamic content. This means compute and data flow globally, not just at edges.

Notice the pattern? The more modern and capable your applications, the more they inherently require global infrastructure. Sovereignty advocates sometimes overlook this: you can't have modern AI features, real-time communication, enterprise-grade security, and microservices observability while staying EU-only. You must choose.

China as a Sovereignty Comparison Point

This is where China's approach is instructive. The Chinese government achieved strict data sovereignty by requiring:

  • All services must be hosted in China by Chinese companies, with Chinese government oversight
  • No foreign CDNs, no global DNS—parallel infrastructure built specifically within China's borders
  • Content filtering at the border—the Great Firewall controls what leaves the country

This achieves sovereignty. But it comes with enormous costs: reduced access to global services, performance penalties, duplicated infrastructure, and complete government surveillance. European organizations don't want this model. So they're left with a tension: you either accept some unavoidable cross-border transfer (like push notifications), or you accept the Chinese model of complete control and complete surveillance.

The uncomfortable truth: there's no middle ground. You can't have perfect sovereignty, world-class performance, secure authentication, and global connectivity simultaneously. Pick three out of four.

This is exactly the kind of transfer that sovereignty frameworks often overlook. It's not AI inference, not model training, not cost optimization. It's fundamental infrastructure that enables modern security and reliability to function. Even intentionally sovereign systems must accept some cross-border transfers because there are no economically viable European alternatives.

The Practical Decision Framework

So how do you actually decide? Here's the framework I recommend:

Step 1: Classify Your Data

Not all data is equal. Classify your data by sensitivity:

  • Public: Marketing content, public documentation. No sovereignty constraints. Use any cloud.
  • Internal: Operational data, internal communications. Moderate constraints. Use US clouds with care, or EU clouds.
  • Sensitive: Personal data (PII), financial records, health information. High constraints. EU data residency required.
  • Strategic/Classified: Trade secrets, strategic plans, classified information. Maximum constraints. Self-host or EU partnership required.

Step 2: Understand Your Regulatory Requirements

What does your industry actually require? GDPR is baseline, but some industries have stricter mandates:

  • Banking (PSD2, MiFID II): EU data centers + audit trails
  • Healthcare (Medical Device Regulation): EU residency + compliance
  • Telecom (EECC, NIS2): EU hosting, managed security operations
  • Critical Infrastructure (NIS2): Likely on-premises or EU partnerships

Step 3: Assess the AI Problem

If you're planning to use AI features (Copilot, machine learning, analytics), ask explicitly:

  • Where is inference happening? (US-based = data leaves EU)
  • Can I opt-out of model training? (Required for sensitive data)
  • Can I enforce EU-only processing? (Usually requires contract negotiation)
  • Is there a European alternative that meets my feature needs? (Honest answer: often no)

Step 4: Make the Trade-Off Decision

Now you choose based on acceptable trade-offs for your organization:

  • Best sovereignty + highest cost: Self-host critical data, use EU clouds for operational needs.
  • Good sovereignty + moderate cost: Use Azure/AWS with mandatory EU data residency, contract restrictions on model training.
  • Acceptable risk + lowest cost: Use US clouds with encryption, audit logging, and acceptance of Schrems II risks.

Final Truth: There is no solution that gives you US cloud pricing, US cloud features, and full EU sovereignty. You must choose what matters most to your business. Most responsible organizations realize they don't need absolute sovereignty for all data—just for the data that actually matters.

Option 4: Microsoft's Sovereign Cloud Solutions—Azure.local and M365.local

There's a newer option that Microsoft has been developing specifically for sovereignty requirements: Azure.local and Microsoft 365 on Local. These are worth understanding because they represent a hybrid approach between full self-hosting and public cloud.

What is Azure.local?

Azure.local is Microsoft's distributed infrastructure solution that extends Azure capabilities to customer-owned on-premises environments. It brings the Azure management plane (Azure portal, CLI, ARM templates, Azure Arc) to your own data center. Key characteristics:

  • On-Premises Deployment: You deploy and manage the hardware yourself, within your facility
  • Full Azure Feature Set: Access to compute, storage, networking, and integrated Azure services
  • Disconnected Operation: Can operate disconnected from the public cloud (offline mode available)
  • Your Data, Your Control: Data never leaves your facility unless you explicitly enable cloud connectivity
  • Per-Core Pricing: Pricing model based on physical cores in your hardware, plus consumption charges for additional Azure services
  • Azure Arc as Control Plane: Unified management across on-premises and cloud deployments

This is designed for organizations with strict sovereignty requirements where data must remain on-premises, but you want the operational benefits of managed Azure services and the cloud-native development experience.

What is Microsoft 365 on Local (M365.local)?

Similar to Azure.local, Microsoft is developing M365.local for organizations that need Microsoft 365 services (Teams, SharePoint, Exchange, etc.) but with data residency mandates. This allows deployment of M365 within your own infrastructure, keeping organizational data on-premises while maintaining the familiar M365 experience and management tools.

The Sovereignty Advantage

These solutions offer genuine sovereignty because:

  • Physical Control: You control the hardware, the facility, the physical security
  • No Data Exfiltration: Your data is processed locally; cloud connectivity is optional and controllable
  • Operational Management: You operate the systems, but with Azure/M365 tooling and support
  • Regulatory Compliance: Can satisfy strict data residency requirements (GDPR, HIPAA, financial regulations)
  • No Cloud Act Exposure: Data doesn't cross borders, so CLOUD Act jurisdiction complications are mitigated

The Trade-Off: Cost and Complexity

Of course, there's a significant catch. Azure.local and M365.local require:

  • Hardware Investment: You purchase and manage the physical infrastructure
  • Operational Burden: You're responsible for maintaining, patching, and securing the hardware stack
  • Scaling Challenges: Scaling requires purchasing and deploying additional hardware (not as seamless as public cloud)
  • Expertise Required: You need staff familiar with hyperconverged infrastructure, Azure Arc, and on-premises cloud management
  • Initial Cost: Higher upfront capital expenditure compared to immediate cloud consumption

So while Azure.local/M365.local give you genuine sovereignty with Microsoft's modern tooling, you're essentially running a private cloud. The operational complexity and cost are closer to self-hosting than they are to public cloud.

The European Agenda: It's Not Personal, It's Strategic

Stepping back: Why is Europe pushing sovereignty so hard? It's not because they think Microsoft is evil. It's because Europe learned a lesson about strategic dependency:

  • Semiconductors: Europe depended on TSMC and Samsung, then got caught short-handed during chip shortages. Now investing €50 billion in local chip manufacturing.
  • Energy: Over-dependence on Russian gas left Europe vulnerable. Now urgently building renewable and alternative supply.
  • Cloud Computing: Almost entirely dependent on US providers. This means European companies can't operate if US policy changes. Europe wants to fix this.

This is reasonable. Europe's goal isn't to ban US clouds; it's to have alternative capacity so European critical infrastructure doesn't depend entirely on US decisions.

For individual organizations, the take-home is: sovereignty is real and worth considering, but it's not binary. Work with your cloud provider, understand what can stay EU-resident, what has to move, and make informed choices about which trade-offs you can accept.

Archives