Resources

EU Cloud Hosting for Startups: Sovereignty, Compliance, and the Real Choices in 2026

om ·

Cloud hosting decisions used to be about price, latency, and developer ergonomics. For any startup serving EU customers in 2026, they’re now also about jurisdiction — specifically, which legal regime can compel access to your data. The shorthand version: physical residency in the EU is not the same as legal sovereignty. This is what’s actually changed, what the real provider options look like, and how to decide what your build needs.

Key takeaways

  • Residency is geography. Sovereignty is jurisdiction. Hosting your data in AWS Frankfurt gives you EU residency. It does not exempt the data from the US CLOUD Act, because Amazon is a US company. For most startups this is fine; for some regulated industries and enterprise B2B sales, it’s a deal-breaker.
  • The 2026 regulatory stack is real. NIS2 (cybersecurity, in force October 2024), DORA (financial services operational resilience, January 2025), and the EU Data Act (cloud switching and portability, September 2025) layer on top of GDPR. Each has different scope; together they raise the floor for cloud architecture.
  • EU-native providers are genuinely competitive. Hetzner, OVHcloud, Scaleway, IONOS, Exoscale offer real performance at materially lower prices than US hyperscalers — but with smaller managed-service portfolios and steeper ops overhead in some cases. The right answer depends on what you need.
  • For most startups, the right answer is not “sovereign-only.” Unless you’re selling into critical infrastructure, regulated finance, healthcare, or public sector, the US hyperscalers’ EU regions remain a defensible choice with the right contractual and technical safeguards.

Residency vs. sovereignty: what the distinction actually means

The terminology gets used loosely. The technical and legal distinctions:

Data residency is geographic. Your data sits on servers physically located in a specific country or region. AWS Frankfurt, Azure West Europe, Google Cloud Belgium — all give you residency in the EU. Most procurement teams looking at “data residency” requirements are satisfied by this.

Data sovereignty is jurisdictional. It asks which country’s laws can compel access to the data, regardless of where it sits. The complication: companies are subject to the laws of their home jurisdiction, not just the jurisdiction of their servers. Amazon, Microsoft, and Google are US companies. Under the US CLOUD Act (passed 2018), US authorities can compel them to produce data in their possession or control — including data physically stored in the EU.

The European Data Protection Board has issued guidance on this conflict. In practice, EU data subjects’ personal data being subject to US-government compulsion creates tension with GDPR Article 48 (which requires that any third-country court order be based on an international agreement, like an MLAT). The big-three US hyperscalers have responded with various “sovereign cloud” offerings — partnerships with European companies, technical isolation, contractual commitments — but the legal reality is that the parent companies remain US-headquartered and remain subject to US law.

For most startups, this isn’t a deal-breaker. For some, it is. The question to answer up front: are any of your customers, or any of your near-term target customers, in sectors that explicitly require EU sovereignty? If yes, you need to architect for it now. If no, you can probably stay on a US hyperscaler’s EU region with proper safeguards.

The 2026 regulatory stack

Four regulations now interact in the cloud-architecture decision. Understanding which apply to your business shapes the right answer.

GDPR (in force since May 2018)

The baseline. Applies to any processing of EU residents’ personal data. Article 48 limits transfers in response to third-country court orders; Article 28 requires DPAs with processors; Schrems II (2020) constrains transfers to the US, with the EU-US Data Privacy Framework (2023) restoring a path for certified US companies. Practical effect on cloud choice: requires Standard Contractual Clauses + Transfer Impact Assessments for non-DPF US processors, and either DPF certification or EU-only hosting for cleaner compliance.

NIS2 Directive (transposition deadline October 2024)

Cybersecurity requirements for “essential” and “important” entities across 18 sectors — including health, finance, energy, transport, digital infrastructure, ICT service management, public administration, and others. NIS2 introduces personal liability for management bodies in cases of non-compliance, supply-chain security obligations (you’re responsible for your providers’ security), and 24-hour initial incident notification with 72-hour follow-up. Practical effect: if you’re in scope or you sell to entities in scope, your cloud provider’s security posture becomes part of your compliance posture.

DORA (in force January 2025)

The Digital Operational Resilience Act, applying to financial entities and their critical third-party ICT providers. Requires documented incident response, threat-led penetration testing for the largest entities, and explicit oversight of “critical ICT third-party service providers” — including cloud providers. The big regulatory change: financial regulators can now directly oversee cloud providers serving financial entities, and contractual exit strategies from those providers are mandatory. Practical effect for fintech startups: you need a documented “exit architecture” showing you can migrate off your primary cloud if required.

EU Data Act (applicable September 2025)

Aimed at data portability and ending vendor lock-in. Requires cloud providers to support customer-initiated switching, with progressive elimination of switching fees (full elimination by 2027), and to make data portable in machine-readable formats. Practical effect: high egress fees and proprietary data formats are now regulated targets. The economic disincentive to leave a hyperscaler is being deliberately reduced.

The real EU-native provider landscape

The European cloud market in 2026 is more mature than most US-based founders realize. The main providers, with the trade-offs honestly stated:

Hetzner (Germany)

The price-performance leader. AMD EPYC instances and dedicated servers at materially lower prices than US hyperscalers — typically 3–5× cheaper for equivalent compute. Data centers in Germany and Finland; no US parent company; subject only to EU and German law. The trade-off: a much smaller managed-service portfolio than AWS or Azure. You get compute, storage, networking, managed databases, Kubernetes — not 200+ services covering every adjacent need. Best for teams comfortable running their own stack on solid IaaS, or teams willing to compose services from multiple providers. Ideal cost-saving target for bootstrapped or runway-conscious startups.

OVHcloud (France)

Europe’s largest cloud provider. Full-stack PaaS portfolio (managed Kubernetes, databases, AI training, object storage), data centers across Europe, Canada, Asia, and Australia. Holds critical European certifications including SecNumCloud (the French government’s highest qualification, designed specifically for cloud services handling sensitive government data) and HDS (Health Data Hosting, required for processing French health data). The certifications matter for healthtech, fintech, and public-sector contracts. Pricing is mid-tier — cheaper than AWS, more expensive than Hetzner. Best for startups targeting regulated EU verticals where the certifications are a sales accelerator.

Scaleway (France)

Strong developer experience with the deepest managed-service portfolio of the EU-native providers. Heavy investment in AI infrastructure — Scaleway operates large GPU clusters in France for AI training, and is the partner of choice for sovereign EU AI work (notably Mistral AI). Managed Kubernetes, serverless functions, managed databases, AI inference endpoints. Pricing comparable to Hetzner for compute but with more bundled value. Best for AI-heavy SaaS, modern React/Node teams that want a developer experience closer to AWS but with EU sovereignty.

IONOS Cloud (Germany)

Enterprise-oriented EU-native cloud. Owned by United Internet, German-headquartered. Strong managed services, BSI C5 certification (the German government’s standard for cloud security), and a clean PaaS layer. Less developer-buzz than Scaleway, more enterprise sales motion. Best for B2B SaaS selling into the German Mittelstand or German public-sector adjacent markets where C5 certification opens doors.

Exoscale (Switzerland)

Privacy-first positioning. Switzerland is outside the EU but has an adequacy decision and stronger privacy protections than most EU countries (cantonal data protection layered on federal protection layered on the Swiss Federal Act on Data Protection). Data centers in Switzerland, Austria, and Germany. Best for DACH-region (Germany-Austria-Switzerland) startups, fintech where Swiss banking-secrecy traditions matter, or startups specifically wanting jurisdictional separation from both the EU and US.

T-Systems Open Telekom Cloud (Germany)

Operated by Deutsche Telekom subsidiary T-Systems, technically built on Huawei’s OpenStack-based platform but operated entirely under German jurisdiction. Strong public-sector positioning. Trade-off: slower release pace than the developer-focused providers, more enterprise-IT-feeling than startup-feeling.

The honest pricing comparison

The published benchmarks (from sources including Vantage, ServerCat, and provider documentation) consistently show EU-native providers at lower price points than US hyperscalers for equivalent compute. The specific multiplier depends on instance type, workload, and which services you actually use — but the general pattern holds: Hetzner for raw compute, Scaleway for managed services with AI, OVHcloud for breadth and certifications. Teams running 24×7 baseline workloads (not bursty) typically save 50–80% on infrastructure costs by moving from AWS to Hetzner or Scaleway. Teams using a lot of AWS managed services (DynamoDB, Lambda, SQS, etc.) save less because the equivalent rebuild on EU providers requires more engineering work.

The US hyperscaler EU region: when it’s actually fine

Defaulting to “EU sovereign only” is the wrong answer for most startups. The US hyperscalers’ EU regions remain a defensible choice when:

  • Your customers are not in regulated EU sectors that explicitly require sovereignty. B2C SaaS, consumer apps, marketing-led B2B SaaS without enterprise EU enterprise customers — the sovereignty argument is weak.
  • You’ve signed the EU-US Data Privacy Framework certification if you’re a US-headquartered company, or your processors have. The DPF (in force July 2023) restores a lawful basis for transfers to certified US companies.
  • You’ve documented a Transfer Impact Assessment per Schrems II and the EDPB recommendations, with supplementary measures (encryption with customer-held keys, access controls, no-government-access guarantees from the provider) where the assessment identifies risks.
  • You’re using EU-only regions explicitly in your provider configuration, with documented controls preventing accidental data movement to US regions.
  • Your DPAs are current (using the post-2021 SCCs, not the deprecated 2010 SCCs) and include sub-processor commitments.

The honest framing: a well-architected AWS Frankfurt deployment with proper Schrems II safeguards is a defensible compliance posture for most startups, and it’s significantly easier to operate than a sovereign-only stack. Don’t burn engineering hours on sovereignty if your business doesn’t need it.

When you actually need EU sovereignty

The cases where the sovereignty argument is real and not theoretical:

  • You’re selling into the EU public sector. Tenders increasingly mandate sovereign cloud, often with specific certifications (SecNumCloud in France, BSI C5 in Germany, ENS in Spain). The hyperscalers’ “sovereign cloud” partnerships have improved here, but EU-native providers remain a cleaner answer.
  • You’re in healthcare processing patient data in regulated EU markets. France’s HDS certification, Germany’s BfArM medical-device requirements, and similar national-level rules push toward EU-native providers with the relevant certifications.
  • You’re in regulated finance under DORA scope. While DORA itself doesn’t mandate EU-only cloud, regulators are scrutinizing US-hyperscaler dependence as a concentration risk. Banks and insurers are increasingly asking for non-US-hyperscaler options.
  • You’re selling enterprise SaaS to large EU enterprises with strict procurement. Many large enterprises have policies preferring or requiring EU sovereignty for certain data classes. The procurement question “can you offer EU-only data residency under EU jurisdiction?” is now standard in enterprise SaaS sales.
  • You’re processing special categories of data under GDPR Article 9 — health, biometrics, ethnicity, political opinions — at scale. The compliance burden is materially lower on a sovereign EU stack than on a US-hyperscaler EU region with documented Schrems II safeguards.

Multi-region architecture for data residency

For SaaS products serving customers across multiple jurisdictions, the practical pattern is multi-region architecture with per-tenant routing. The implementation:

Edge routing at the request layer

Every request is tagged with the resolved tenant’s region (EU, US, etc.) before any data is read or written. Next.js middleware on Vercel Edge, Cloudflare Workers, or equivalent intercepts requests, looks up the tenant’s region from a global registry (cached at the edge), and routes to the correct regional cluster. The tenant-to-region mapping is the only piece of “tenant identity” data that’s globally replicated; everything else stays regional.

Regional database isolation

Separate database instances per region, with no cross-region replication of personal data. Tools like Prisma Accelerate, PlanetScale’s region-aware deployments, or Aurora Global Database (with explicit per-row region pinning) make this manageable. The data model needs to support it from day one — retrofitting cross-region isolation onto a globally replicated database is significantly harder than designing for it.

Customer-managed encryption keys (CMEK / HYOK)

For the strongest sovereignty posture: encrypt customer data with keys held by the customer in their own KMS (HSM, AWS KMS in the customer’s account, or a sovereign EU HSM service). The cloud provider stores ciphertext only and cannot decrypt the data even if compelled. Operationally complex — every authorized read requires a key-fetch from the customer’s KMS — but it makes the sovereignty story technical rather than purely contractual.

Backup and DR architecture

Backups stay in the same region as the source data. Cross-region backup replication is a sovereignty hole if not handled carefully. The mature pattern: per-region backup, with documented restore procedures that include cross-referencing against deletion requests so user data deleted under GDPR Article 17 isn’t accidentally re-introduced from a backup. “We can’t restore that account, it was deleted last month” is a feature, not a bug.

The auth layer: the often-overlooked sovereignty gap

One of the most common sovereignty gaps in 2026 SaaS architectures: the authentication provider. Auth0 (Okta) is US-based. Clerk is US-based. Stytch is US-based. Even when your application data sits in the EU, your users’ identity data — emails, login timestamps, device fingerprints, MFA secrets — sits with a US provider and is subject to the same CLOUD Act exposure as any other US-hosted data.

EU-native alternatives that have matured into production-ready options:

  • ZITADEL (Switzerland). Open-source, multi-tenant by design, event-sourced (giving you immutable audit logs that satisfy DORA and NIS2 reporting requirements). Self-hostable or managed. Strong choice for B2B SaaS with enterprise customers who’ll ask about identity-data residency.
  • Ory (Germany). Open-source identity infrastructure (Kratos for identity, Hydra for OAuth/OIDC, Keto for permissions). API-first, very flexible, requires more integration work than Auth0 but gives you full control. Best for teams that want to compose their auth stack rather than buy a fully-managed product.
  • Hanko (Germany). Passwordless-first (passkeys via FIDO2), modern UX, EU-headquartered. Strong choice for B2C apps where the friction of password-based auth is itself the conversion problem.
  • Logto (Singapore-headquartered with EU data residency option). Open-source, recent entrant, growing. Worth evaluating if you want a Clerk-style developer experience.

Migrating an existing app from Auth0 to ZITADEL or Ory is non-trivial — user records, MFA factors, sessions all need to migrate — but it’s well-documented. For new builds, picking an EU-native auth provider from day one removes a sovereignty gap before it exists.

FAQ

Does my US-headquartered SaaS need to host in the EU?

If you have EU customers, you need to comply with GDPR — but that doesn’t automatically require EU hosting. The cleanest paths: certify under the EU-US Data Privacy Framework (free, voluntary, restores a lawful transfer basis to your US-hosted services), or offer EU customers a regional deployment with EU data residency. The DPF certification is the lighter lift; regional deployment is the more defensible answer for enterprise EU customers who’ll ask hard questions in procurement.

Is Hetzner production-ready for serious workloads?

Yes, with caveats. Hetzner runs production workloads for many companies, including ones doing serious traffic volumes. The caveats: smaller managed-service portfolio, less mature multi-region tooling than AWS, and historically less of an enterprise-support reputation than the hyperscalers (though their support has improved materially). Best for teams comfortable running Kubernetes themselves and operating their own stack; less ideal for teams that lean heavily on AWS-managed services.

What about hyperscaler “sovereign cloud” offerings?

AWS European Sovereign Cloud (announced 2023, rolling out through 2026), Microsoft EU Data Boundary, Google Sovereign Cloud partnerships — each tries to address sovereignty concerns through technical isolation, EU-staffed operations, and partnerships with European companies. Whether they fully resolve the CLOUD Act question is contested. The legally cleaner answer remains EU-native providers with no US parent. The pragmatic answer for many startups is the hyperscaler EU region with documented safeguards — the sovereign cloud offerings sit somewhere in between with higher cost and more complex contracts.

What’s the actual cost of running on Hetzner or Scaleway vs AWS?

For baseline always-on workloads, expect to spend 50–80% less on infrastructure than equivalent AWS spend. The savings are largest for compute (Hetzner’s pricing is dramatically lower than AWS for equivalent vCPU/RAM). The savings are smaller (or sometimes reversed) when you’re heavy on AWS-managed services that don’t have direct equivalents — you’ll spend the difference on engineering time to compose services from primitives. The honest break-even: small teams running standard web/API workloads save real money on EU-native providers. Teams running heavy serverless / DynamoDB / SQS / Lambda architectures need to think about migration cost vs ongoing savings.

Is the EU AI Act going to mandate sovereign AI?

The AI Act (in force August 2024, applying in stages through 2026 and 2027) doesn’t mandate EU-hosted AI broadly, but it imposes significant requirements on “high-risk” AI systems and general-purpose AI models. Combined with GDPR’s existing constraints on AI training and processing of personal data, the practical pressure is toward sovereign AI for regulated EU sectors. Mistral, Aleph Alpha, and Silo AI provide EU-native LLM options; Scaleway and others provide EU-hosted GPU infrastructure for self-hosted models. For most startups, OpenAI’s EU data residency offering or Anthropic’s enterprise EU options are sufficient; for regulated EU sectors, the sovereign-AI question is increasingly real.

Want help architecting this?

EtherLabz architects multi-region cloud deployments across both US-hyperscaler and EU-native stacks — and we’ll tell you honestly when sovereignty is the right answer for your business and when it’s a distraction from shipping. If you’re trying to figure out where your build should run, or migrating an existing stack to satisfy enterprise EU procurement requirements, book a discovery call.

Written by Shadow, with input from the EtherLabz team. This article is general guidance, not legal advice. Cloud-jurisdiction decisions should involve qualified counsel familiar with your specific situation and customer base.