A US hyperscaler's EU region keeps your data in Europe physically — not legally. Here's when Hetzner genuinely wins, when AWS EU is still the right call, and how to decide.

EU-sovereign cloud hosting means infrastructure where all three layers sit inside the EU: where the data physically lives, which company operates the platform, and which legal system can compel access to it. A Frankfurt region on a US hyperscaler delivers the first layer — and only the first.

The short answer: if a provider is subject to US jurisdiction, the CLOUD Act lets US authorities compel it to hand over data it controls, no matter which country the servers stand in. That doesn’t make AWS or GCP unusable for German companies — for most workloads, an EU region with customer-managed keys is a defensible setup. But it does mean “our data is in Frankfurt” is a statement about latency, not sovereignty. And once you separate the legal question from the economic one, a second surprise appears: for steady-state, traffic-heavy workloads, EU providers like Hetzner aren’t just the sovereign choice — they’re often dramatically cheaper. The trick is knowing which of your workloads belong where.

We architect cloud platforms for mid-market DACH companies across AWS, GCP, and Hetzner, and this question — “is our Frankfurt region actually compliant, and are we overpaying for it?” — has become the most common opener in our cloud architecture engagements. Here’s the full picture.

What the CLOUD Act actually reaches

The Clarifying Lawful Overseas Use of Data Act became US law in 2018. Its core mechanism is simple: US authorities can require a provider subject to US jurisdiction to produce data in its “possession, custody, or control” — regardless of where that data is stored. The physical location of the server is legally irrelevant. What matters is who controls it.

For years, hyperscaler sales decks answered this with process language: requests are rare, they’re challenged in court, there are transparency reports. All true. Then, in June 2025, the abstraction collapsed into a single sentence. Testifying before a French Senate inquiry into digital sovereignty, Microsoft France’s director of public and legal affairs was asked whether he could guarantee that French citizens’ data would never be transmitted to US authorities without French authorization. His answer, under oath: “No, I cannot guarantee it.”

That is not a scandal — it’s just the law working as written. A US-headquartered provider cannot contract its way out of a US statute, and no amount of EU data-center investment changes the jurisdiction of the parent company.

For most companies, the practical exposure is small — CLOUD Act orders against ordinary mid-market firms are rare. But “rare” is doing heavy lifting in a lot of compliance documentation. If you process health data, run critical infrastructure, serve public-sector clients, or hold trade secrets a US competitor would enjoy reading, your works council, your DPO, and increasingly your enterprise customers will ask the jurisdiction question. “Frankfurt region” is not an answer to it.

“We’ll just use the sovereign cloud”

The hyperscalers know all this, which is why the AWS European Sovereign Cloud exists: a €7.8 billion investment, a first region in Brandenburg launched at the start of 2026, operated by a German parent company (AWS European Sovereign Cloud GmbH) under German law, with EU nationals as managing directors and a commitment that customer content and metadata stay inside EU boundaries.

Credit where due — this is a serious structural effort, not a marketing region. For many organizations, it will be enough. But we’d be doing you a disservice if we skipped the fine print: the ultimate parent remains a US corporation, and legal commentators openly question whether the corporate structure would hold against a determined US court order backed by contempt sanctions against the parent. The Microsoft France testimony is instructive here — Microsoft also operates EU datacenter regions with extensive contractual safeguards, and its own lawyers declined to guarantee the outcome.

So treat “sovereign cloud” offerings as risk reduction, not risk elimination. Where the distinction matters — and where it doesn’t — is a per-workload decision, which is exactly why the economics deserve a seat at the same table.

Where Hetzner genuinely wins: the economics

Hetzner is a German hosting company, founded 1997, with its main data centers in Falkenstein and Nuremberg (plus Helsinki for EU workloads). A German operator, German data centers, German legal jurisdiction — the sovereignty box is simply ticked, without a whitepaper explaining why it’s complicated. What surprises most clients is the second half: the price list.

The single most dramatic difference is traffic. AWS charges roughly $0.09/GB for data transfer out of its EU regions to the internet (after a free 100 GB/month), with volume discounts that only start to matter at tens of terabytes. Hetzner includes 20 TB of traffic with every cloud server and charges around €1.19/TB beyond that.

Compute shows the same pattern, less extreme but still decisive for always-on workloads: public comparisons have consistently put equivalent Hetzner resources at a fraction — commonly a third to a fifth — of on-demand hyperscaler pricing once storage and traffic are included. Where this compounds is steady-state: the database that runs 24/7, the data pipeline that processes every night, the API that serves constant traffic. Hyperscaler pricing is built for elasticity you’re not using; you’re paying an availability premium on capacity you occupy permanently.

The workloads where this math lands hardest:

• Steady-state compute — databases, Kubernetes worker pools, schedulers, internal tools. Anything running at predictable load around the clock.
• Egress-heavy systems — media delivery, backups and disaster-recovery replication, data products serving files or feeds to customers, ML training data movement.
• Dev, staging, and CI — environments that don’t need five nines or managed anything, but quietly consume a third of many hyperscaler bills.

Where Hetzner loses — and AWS EU is the right answer

We’d rather tell you this now than after a migration: Hetzner is infrastructure, not a platform. There is no RDS, no BigQuery, no SageMaker, no managed Kafka. Every managed service you lean on today becomes something your team runs — or something we containerize, automate, and hand over with runbooks. That’s very doable with modern tooling, but it is not free, and pretending otherwise is how “cheap hosting” turns into an ops crisis.

There’s also the compliance-certification angle, which cuts both ways: hyperscalers bring BSI C5 attestations, ISO stacks, and audit artifacts that enterprise procurement departments recognize on sight. If your sales cycle depends on those documents this quarter, that’s a legitimate reason to be on AWS EU — sovereignty debates don’t pay invoices.

The Data Act just changed the exit math

One more variable moved recently. The EU Data Act has applied since 12 September 2025, and its cloud-switching provisions are aimed squarely at lock-in: providers must remove obstacles to switching, switching charges are capped at demonstrable cost during a transition period, and from 12 January 2027 charges for the switching process — including the data egress involved in moving out — are banned outright. The hyperscalers saw it coming: AWS already waives egress fees for customers migrating off the platform entirely, on request, since March 2024.

Day-to-day operational egress is untouched — the €0.09/GB meter still runs while you stay. But the one-time toll gate at the exit is being dismantled, which changes the strategic calculus: the cost of trying Hetzner for a workload class, or of splitting your estate, has never been lower. Vendor lock-in is increasingly a function of your architecture (proprietary managed services, console-built infrastructure) rather than your provider’s pricing — which is exactly the part you can engineer away with infrastructure-as-code.

A pragmatic decision framework

We don’t run this as a religious debate — hyperscaler versus bare metal — but as a per-workload sort. The version below is compressed from what we do in the first two weeks of an engagement:

1. 01

   Classify data by sovereignty requirement

   Sort every data class into three buckets: must never be reachable by non-EU jurisdiction (health data, public-sector, works-council-sensitive HR, crown-jewel IP), should stay EU-resident with safeguards (most personal and commercial data), and location-agnostic (public assets, ephemeral compute). Most companies discover the first bucket is 10-20% of their estate — not 100%, and not 0%.

   ⏱ Step 1

2. 02

   Profile the workload shape

   Pull 12 months of billing data and separate steady-state from elastic consumption. Anything running above ~60% average utilization around the clock is a candidate for fixed EU infrastructure; genuinely spiky workloads earn their hyperscaler premium. Flag egress-heavy systems separately — they are usually the fastest wins.

   ⏱ Step 2

3. 03

   Price the exit, not just the hosting

   For each managed service, estimate the self-managed equivalent honestly: software, engineering hours, on-call load. Some swaps are near-free (object storage, container runtime); some are expensive (a well-tuned BigQuery). Where the swap is expensive, staying put with customer-managed keys and a documented transfer impact assessment is the grown-up answer.

   ⏱ Step 3

4. 04

   Split the estate — in code

   The end state is usually hybrid: bucket-one data and steady-state compute on EU-jurisdiction infrastructure (Hetzner or similar), elastic and managed-service-dependent workloads on AWS/GCP EU regions with CMK encryption. Everything in Terraform or Pulumi, so the boundary between the two is a variable, not a rewrite.

   ⏱ Step 4

That hybrid split is what we built for a healthcare client whose patient-adjacent data legally could not sit under US jurisdiction: the EU-sovereign customer data platform runs the sensitive core on EU infrastructure while keeping the door open for elastic workloads elsewhere. No single-vendor purity — just each workload where it’s defensible and cheapest.

For what it’s worth, we hold ourselves to the same sort: this website, our analytics, and our internal tooling run on Hetzner — steady-state, egress-light, sovereignty-clean, and boring in the best way. Our clients’ burst compute runs where burst compute belongs.

Not sure which bucket your workloads fall into?

Send us a rough sketch of your stack and last quarter’s cloud bill. We’ll tell you what genuinely needs EU jurisdiction, what’s overpaying for elasticity it never uses, and what should stay exactly where it is.