EU Region vs EU-Owned Cloud: What Your Data's Address Misses

Hosting your infrastructure in an EU region of a US cloud provider—such as AWS eu-central-1 in Frankfurt or Azure West Europe in Amsterdam—means your servers sit physically inside the European Union, which gives you data residency. Using an EU-owned cloud—such as UpCloud, Scaleway, OVHcloud, or Hetzner—means both the physical servers and the parent company are headquartered in Europe and governed solely by European law, which gives you jurisdictional sovereignty. For many European companies, an EU region is enough to lowers network latency and satisfy basic data location rules. However, if your compliance requirements, customer contracts, or risk models require immunity from extraterritorial foreign laws like the US CLOUD Act, physical location alone does not solve the problem.

Key takeaways

Data residency is not data sovereignty: Residency is where your data is physically stored; sovereignty is which country’s laws control the company that operates the servers.
US parent companies remain under US jurisdiction: Under the US CLOUD Act, US authorities can compel US cloud providers to hand over data under their control, regardless of whether that data is stored in Frankfurt, Dublin, or Virginia.
“Sovereign” compartments still have US roots: Products like the AWS European Sovereign Cloud isolate operations and staff inside the EU, but the ultimate parent entity remains a US corporation.
Not all workloads need the same level of control: Many B2B SaaS teams can run safely in an EU region of a US cloud, while teams selling to the European public sector, healthcare, or defense increasingly need an EU-owned provider.
Exit rules are tightening: The EU Data Act and DORA are making it legally and financially easier to switch cloud providers, removing traditional lock-in barriers by January 2027.

Residency vs. jurisdiction: two different questions

When a prospective enterprise customer or data protection officer asks, “Where is our data hosted?”, they are usually asking two separate questions at once.

The first question is physical: In which city and country do the hard drives holding our database sit? This is data residency. If you select the Frankfurt, Stockholm, or Paris region in your AWS, Google Cloud, or Azure console, your customer data stays on servers inside that geographic boundary (unless you configure cross-region backups or global services like CDNs and IAM that replicate metadata globally).

The second question is legal: Which government has the authority to compel the cloud provider to grant access to, freeze, or hand over our systems? This is jurisdiction (often called data sovereignty). Jurisdiction follows corporate ownership and control, not just server racks.

If a cloud provider is headquartered in the United States—or is a wholly owned subsidiary of a US corporation—it is subject to US law alongside the local laws of the countries where it operates. If a cloud provider is headquartered in Finland, France, or Germany, with no corporate parent outside Europe, it is subject to national and EU law.

How extraterritorial laws cross physical borders

To understand why the parent company’s passport matters, you have to look at how modern legal frameworks treat cloud providers.

The US CLOUD Act and FISA Section 702

In 2018, the United States passed the Clarifying Lawful Overseas Use of Data (CLOUD) Act. The law amended the Stored Communications Act to state that a US service provider must preserve, backup, or disclose electronic data in its “possession, custody, or control,” regardless of whether that communication or record is located within or outside of the United States.

Separately, Section 702 of the US Foreign Intelligence Surveillance Act (FISA) allows US intelligence agencies to compel electronic communication service providers to assist in acquiring foreign intelligence information targeting non-US persons located outside the United States.

In practice, law enforcement agencies rarely go after ordinary B2B software databases, and US cloud providers publish transparency reports showing they push back against overly broad requests. Furthermore, the EU-US Data Privacy Framework (DPF), adopted by the European Commission in July 2023, currently provides a valid legal mechanism under the GDPR for transferring personal data to participating US companies, following binding commitments from the US government to limit intelligence access to what is “necessary and proportionate.”

Why legal tension remains

Despite the Data Privacy Framework, legal tension remains for two reasons:

Direct conflict with GDPR Article 48: Article 48 of the GDPR states that any judgment of a court or decision of an administrative authority of a third country requiring a controller or processor to transfer or disclose personal data may only be recognized or enforceable if based on an international agreement, such as a mutual legal assistance treaty (MLAT). A direct order under the US CLOUD Act bypasses the MLAT process, putting a US provider’s European subsidiary in a bind between US law and EU law.
Schrems challenges: The two previous transatlantic data frameworks (Safe Harbor and Privacy Shield) were invalidated by the Court of Justice of the European Union (CJEU) in the Schrems I and Schrems II rulings. Many European legal teams treat the current DPF as stable for now, but build infrastructure plans assuming a third challenge could happen in the future.

What about “EU Sovereign Cloud” offerings from US hyperscalers?

Recognizing that European public sector bodies and regulated industries are uneasy about US jurisdiction, AWS, Microsoft, and Google have all launched specialized “sovereign” offerings in Europe.

For example, the AWS European Sovereign Cloud creates a separate physical and logical partition in Germany. It is operated exclusively by EU residents, keeps all metadata (including billing and configuration logs) inside the EU, and uses an independent European advisory board. Microsoft offers the EU Data Boundary, and Google offers Sovereign Controls with local partners like T-Systems or Thales.

These offerings solve specific operational risks:

They prevent support engineers outside the EU from accidentally accessing your environment during a ticket escalation.
They keep operational metadata (like resource names, tags, and IAM roles) inside the EU, which standard regions sometimes replicate back to the US.

However, they do not change the ultimate cap table. The AWS European Sovereign Cloud is still owned by Amazon.com, Inc., a US company. If the core requirement of your customer or regulator is that the provider has no corporate nexus to a non-EU jurisdiction, a sovereign partition on a US hyperscaler does not fully close that gap.

How to mitigate risk if you stay in an EU region

For many companies, moving off AWS or GCP immediately isn’t practical. Developers know the tools, or the application relies on proprietary services. If you stay in an EU region of a US cloud, how much protection does encryption give you?

Standard provider-managed encryption (KMS): Encrypting data at rest using the cloud provider’s native Key Management Service protects you if someone steals a physical hard drive from the data center. It does not protect against a lawful order served to the provider, because the provider controls the keys.
Bring Your Own Key (BYOK): You generate the encryption keys yourself and upload them to the cloud provider’s hardware security module (HSM). You can revoke the key, but while your application is running, the cloud provider’s infrastructure still holds the key in memory to read and write data.
Hold Your Own Key (HYOK) / External Key Management: Your keys live on a separate server outside the cloud provider (for example, in your own vault or an EU-owned key manager), and data is encrypted before it ever reaches the US cloud. This satisfies strict Schrems II technical measures, though it effectively reduces the cloud provider to “dumb storage” and makes it impossible to use most managed databases or compute services that need to process cleartext data.

Side-by-side comparison: EU Region vs. EU Sovereign Partition vs. EU-Owned Cloud

Feature / Dimension	US Cloud — Standard EU Region (e.g., AWS Frankfurt)	US Cloud — EU Sovereign Partition (e.g., AWS European Sovereign Cloud)	EU-Owned Cloud (e.g., UpCloud, Scaleway, OVHcloud, Hetzner)
Physical location of customer data	Inside the EU	Inside the EU	Inside the EU
Location of account & operational metadata	Often replicated globally / to the US	Inside the EU	Inside the EU
Support & operations staff	Global (follow-the-sun model)	EU residents only	Predominantly EU residents
Ultimate parent company HQ	United States	United States	European Union (Finland, France, Germany, etc.)
Subject to US CLOUD Act?	Yes	Legal grey area; parent company remains US-based	No (unless the provider has significant US operations/subsidiaries)
Breadth of proprietary PaaS services	Very high (hundreds of managed services)	Moderate to high (subset of standard region services)	Focused on core IaaS and open-source PaaS (VMs, K8s, Postgres, S3)
Data egress pricing structure	High per-GB fees after small free tier (until EU Data Act rules take full effect)	High per-GB fees (similar to standard regions, plus sovereign premium)	Typically bundled generous transfer allowances or low flat rates (check provider pricing pages)

Note on EU-owned clouds and US presence: Some larger European providers have US data centers or US sales subsidiaries. Strictly speaking, a US court can serve an order on a European company that has sufficient “minimum contacts” or a subsidiary in the US, though doing so to extract European customer data from European servers would face immediate blocking statutes and GDPR enforcement in Europe.

Beyond privacy: operational autonomy, DORA, and the EU Data Act

For years, the conversation around EU clouds focused entirely on the GDPR and personal data. Since 2025, the focus for European CEOs and CFOs has expanded to operational continuity and vendor lock-in.

DORA (Digital Operational Resilience Act)

Applicable since 17 January 2025, DORA (Regulation (EU) 2022/2554) governs financial entities in the EU and their critical ICT third-party service providers. If your company is a fintech, an insurtech, or a SaaS vendor selling into banks, DORA impacts you. It requires explicit exit strategies, tested migration plans, and avoidance of concentration risk for ICT services supporting critical or important functions. Relying entirely on proprietary services inside a single US hyperscaler makes passing a DORA vendor audit harder.

The EU Data Act and the end of egress lock-in

Historically, moving data out of a US cloud’s EU region was punishingly expensive due to data egress fees. The EU Data Act (Regulation (EU) 2023/2854) changes the economics of switching cloud providers. Under Article 29 of the Data Act:

During the transition period until 12 January 2027, cloud providers may only pass on the direct costs incurred for switching (including data egress for switching purposes).
Starting 12 January 2027, switching charges—including data egress fees when moving to another provider—are completely banned across the EU.

Predictable billing and open standards

While US clouds offer hundreds of specialized services (like DynamoDB, BigQuery, or Cognito), most 10-to-300-person European technology companies actually run standard workloads: Linux virtual machines, Docker containers on Kubernetes, PostgreSQL or MySQL databases, Redis caches, and S3-compatible object storage.

EU-owned providers—such as UpCloud (Finland), Scaleway and OVHcloud (France), Hetzner, STACKIT, and IONOS (Germany), and Exoscale (Switzerland/Austria)—build their platforms around these open standards. Because they do not wrap standard open-source software in complex proprietary billing meters, monthly infrastructure costs are typically lower and much easier to forecast.

Practical checklist: Which setup fits your company?

Use this checklist with your engineering and legal leads to decide whether your current cloud setup matches your business reality.

Staying in a standard EU region of a US cloud makes sense if:

Your customers are mostly private-sector businesses that accept standard GDPR Data Processing Agreements (DPAs) and the EU-US Data Privacy Framework.
Your engineering team relies heavily on proprietary cloud services (e.g., AWS DynamoDB, Google BigQuery, Azure Cosmos DB) that would require rewriting application code to leave.
Your primary motivation is low network latency for European users rather than geopolitical or jurisdictional insulation.

Moving to an EU-owned cloud makes sense if:

You sell (or plan to sell) to European public sector bodies, healthcare providers, defense contractors, or strict financial institutions that mandate EU-headquartered sub-processors.
Your architecture runs primarily on portable building blocks: VMs, Kubernetes, PostgreSQL/MySQL, Redis, and S3-compatible storage.
You need a verifiable exit strategy under DORA, or you want to eliminate single-vendor concentration risk.
You want predictable monthly infrastructure bills without paying a premium for services you don’t use or unexpected data transfer charges.

Frequently asked questions

No. The GDPR does not ban the use of US-owned cloud providers, nor does it strictly require data to stay inside the EU, provided a valid transfer mechanism (like the EU-US Data Privacy Framework or Standard Contractual Clauses with supplementary measures) is in place. However, using an EU-owned cloud eliminates third-country transfer assessments and protects against the risk of future transatlantic data frameworks being struck down in court.

Can the US government really demand my data if it’s stored in AWS Frankfurt?

Legally, the US CLOUD Act gives US authorities the power to compel a US company to produce data under its control, regardless of where the servers are located. In practice, US cloud providers challenge requests that conflict with foreign laws, and the US Department of Justice generally seeks data directly from the enterprise customer first rather than the cloud provider. Still, for regulated industries, the existence of that legal authority is a compliance risk they prefer to avoid altogether.

Are EU-owned clouds ready for production SaaS workloads?

Yes, for standard architectures. Providers like UpCloud, Scaleway, OVHcloud, STACKIT, IONOS, and Exoscale offer managed Kubernetes, managed PostgreSQL and MySQL with high availability, load balancers, private networking, and S3-compatible object storage, along with ISO 27001 certifications. (Hetzner offers high-performance dedicated and cloud servers at very low prices, though managed databases and Kubernetes must be set up on servers directly.) Where EU clouds differ from US hyperscalers is that they do not offer dozens of niche, proprietary AI, IoT, or global NoSQL products.

Will moving from an EU region to an EU-owned cloud require rewriting our application?

If your application uses standard technologies—like Docker containers, Linux VMs, PostgreSQL, MySQL, Redis, and S3 APIs—you do not need to rewrite application code. You only need to rebuild the underlying infrastructure (networks, firewalls, compute, and managed databases) on the new provider and update your deployment pipelines. If your application is tightly coupled to proprietary services like AWS Lambda, Step Functions, and DynamoDB, migrating requires refactoring those components first.

How MoveInfra can help

If you decide that an EU region is no longer enough and want to move to an EU-owned cloud like UpCloud, Scaleway, Hetzner, or OVHcloud, MoveInfra handles the migration for a fixed price. We analyze your current AWS, Google Cloud, Azure, or DigitalOcean setup, rebuild your environment as Terraform code on the target EU cloud, sync your databases and object storage live, and help you switch DNS with a short planned write pause once replication lag is under five seconds. We also keep reverse replication running for 30 days so you have a clear rollback option before shutting down your old environment.