After the Dutch Central Bank Ditched AWS: What EU Cloud Sovereignty Means for Developer Hosting

Earlier this year, a story landed on Hacker News with over 360 points and 148 comments: De Nederlandsche Bank (DNB) — the Dutch central bank and prudential supervisor — had migrated away from AWS to a European cloud provider. The thread ran hot with developers asking variations of the same question: if a central bank can't trust a US cloud provider, what does that mean for the rest of us?

This post explains the regulatory logic behind the DNB's move, what "EU cloud sovereignty" actually means in legal terms, and what practical options exist for EU developers who need to make similar decisions.

What Happened: DNB and the Shift to EU Cloud

De Nederlandsche Bank (DNB) is the Dutch central bank and the national prudential supervisor, part of the European System of Central Banks. It regulates Dutch banks, insurers, and pension funds, oversees payment system stability, and manages foreign exchange reserves.

The reported move away from AWS and toward a European cloud provider — specifically one connected to the Schwarz Group (the German retail giant behind Lidl and Kaufland), whose cloud arm operates under the brand STACKIT — is a significant signal. Central banks operate under some of the strictest data sovereignty requirements in the world, and when they vote with their infrastructure budget, EU compliance teams notice.

Why would DNB move? The short answer is that for critical financial infrastructure, the CLOUD Act makes US-based cloud providers legally incompatible with EU regulatory requirements — not theoretically, but structurally.

The CLOUD Act Problem for EU Critical Infrastructure

The Clarifying Lawful Overseas Use of Data (CLOUD) Act (2018) gives US federal law enforcement agencies the authority to compel any US-headquartered company — including AWS (Amazon), Microsoft Azure, and Google Cloud — to produce data stored anywhere in the world, including in EU-based data centers. No EU notification is required. No GDPR breach notification is triggered. The data subject's national authority has no automatic recourse.

For a central bank processing monetary policy data, financial system stress test results, proprietary economic models, and personally identifiable information about individuals under investigation for financial crime, this exposure is categorically unacceptable.

GDPR Article 48 directly addresses this tension. It states that judgments of courts and decisions of administrative authorities of a third country requiring data transfer or disclosure may only be recognized if based on an international agreement in force between the requesting third country and the EU. No such CLOUD Act-compatible agreement currently exists between the EU and the United States.

DORA — the Digital Operational Resilience Act (Regulation EU 2022/2554), which became applicable in January 2025, tightens this further for financial entities. DORA requires financial institutions to maintain:

Concentration risk management: Regulators must be able to audit third-party ICT providers. A US provider subject to CLOUD Act orders may be legally prevented from disclosing certain information to EU supervisors.
Exit strategies: Institutions must demonstrate they can exit a cloud provider relationship without operational disruption. Multi-year dependency on a single US hyperscaler contradicts this.
Contractual audit rights: Under DORA Article 30, ICT contracts must include rights of access, inspection, and audit by the financial entity and by competent authorities. CLOUD Act gag orders can directly conflict with these contractual audit rights.

For a central bank operating under DORA and supervising institutions that must also comply, running critical workloads on AWS creates a compliance surface that is difficult to fully resolve even with EU data residency options.

What Is STACKIT? The "Lidl Cloud" Explained

STACKIT is the cloud infrastructure brand of the Schwarz Group — the privately held German conglomerate that owns Lidl and Kaufland. With over €130 billion in annual revenue, the Schwarz Group is one of the largest companies in Europe. STACKIT operates entirely from data centers within Germany and the EU, making it a legally distinct entity from US hyperscalers.

Why does the "Lidl Cloud" branding stick, even though STACKIT has little to do with retail operations? Because the Schwarz Group's ownership means:

No US parent company: Unlike AWS (Amazon US), Azure (Microsoft US), or GCP (Google US), STACKIT has no US corporate parent that can be served a CLOUD Act order.
German courts jurisdiction: Legal disputes fall under German and EU law, not US federal jurisdiction.
GDPR as native compliance framework: EU data protection law is the baseline, not an add-on.

STACKIT offers compute, Kubernetes, object storage, managed databases, and developer tools — a reasonable subset of what AWS offers, positioned specifically for EU regulated industries, government, and enterprises that need verifiable data sovereignty.

Other EU-native cloud providers in the same category include:

Provider	HQ	Differentiator
STACKIT	Germany	Schwarz Group, regulated industry focus
Hetzner	Germany	Developer-friendly, excellent price/performance
OVHcloud	France	Large-scale IaaS, public cloud alternative
IONOS	Germany	SME and developer focus
Exoscale	Switzerland	Swiss data protection law
UpCloud	Finland	High-performance SSD, EU-only

The Compliance Signal: What Central Bank Decisions Mean for SaaS Developers

Here is the key insight that the HN thread surfaced: central bank decisions are leading indicators for regulatory requirements that will eventually cascade down to the companies they supervise — and then to the SaaS vendors those companies use.

The pattern works like this:

Regulators move first. Central banks, financial supervisors, and government agencies face the strictest interpretations of GDPR, DORA, NIS2, and the CLOUD Act problem. Their procurement decisions reveal the compliance ceiling.
Regulated industries follow. Banks, insurers, and healthcare providers under NIS2 and DORA must demonstrate supply chain resilience and ICT third-party risk management. When their regulator uses an EU cloud, the implicit expectation shifts.
SaaS vendors get asked. The banks and hospitals that move to EU cloud providers start asking their SaaS vendors — your CRM, your analytics tool, your deployment platform — where data is processed and whether a CLOUD Act order could reach it.
Procurement requirements tighten. Data Processing Agreements now routinely include questions about third-country transfers, sub-processor US exposure, and exit strategy documentation.

If you are building a SaaS product that serves European regulated industries — fintech, healthtech, legaltech, govtech — the DNB's move is not just an interesting news story. It is a preview of what your enterprise sales cycle will require in 12-24 months.

What "EU Sovereignty" Actually Requires: A Developer Checklist

EU cloud sovereignty is frequently oversimplified as "data stored in Europe." The DNB's move illustrates why storage geography is necessary but not sufficient. Here is what the full requirement actually includes:

1. Legal Jurisdiction of the Provider

Not sufficient: AWS EU-West (Ireland) — Amazon Inc. is a US company, subject to CLOUD Act.

Sufficient: STACKIT, Hetzner, OVHcloud — EU/non-US parent company, EU-law governed.

The legal question is: Can a US court issue a valid compulsion order to the provider's parent company? If yes, EU data residency does not resolve the Art.48 exposure.

2. Sub-Processor Chain

Even if you move to an EU cloud provider, your infrastructure might include:

US-headquartered CDN (Cloudflare, Fastly) — US parent CLOUD Act exposure
US-headquartered observability tools (Datadog, Sentry, New Relic) — application logs, stack traces with PII
US-headquartered CI/CD (GitHub Actions) — source code and secrets

Each sub-processor with US corporate lineage reintroduces CLOUD Act exposure. Full sovereignty requires auditing the entire sub-processor chain, not just your primary cloud provider.

3. Contractual Audit Rights Under DORA

For financial sector clients (and increasingly healthcare under NIS2), your contracts must include:

Right of the customer to audit your infrastructure
Right of the customer's regulator to audit your sub-processors
Documented exit strategy

US providers may have CLOUD Act restrictions that prevent full disclosure to EU regulatory auditors. EU-native providers do not have this problem structurally.

4. Data Processing Agreement Completeness

Your DPA must document:

All sub-processors (with country of incorporation)
Transfer mechanisms for any third-country processing (Standard Contractual Clauses for residual US exposure)
Technical and organizational measures (TOMs)
Retention and deletion procedures

GDPR enforcement has focused increasingly on DPA completeness, not just data location.

The Developer Hosting Decision

For EU developers, the DNB story raises a practical question: where should you deploy your application if EU sovereignty is a selling point — or a requirement?

Option 1: US Hyperscaler EU Regions (AWS eu-west, Azure West Europe, GCP europe-west)

What it gets you: Mature tooling, large feature set, global CDN, well-understood pricing.

What it does not get you: Resolution of CLOUD Act exposure from the US parent company. Suitable for applications where EU data residency is a soft preference but not a hard regulatory requirement.

Option 2: EU-Native IaaS (Hetzner, STACKIT, OVHcloud)

What it gets you: No US parent CLOUD Act exposure. Strong price-performance (Hetzner is typically 3-5x cheaper than AWS for comparable compute). EU legal jurisdiction.

What it requires: More infrastructure work — you manage Kubernetes, load balancers, databases, and the operational overhead yourself unless you build on top of managed services.

Option 3: EU-Native PaaS (sota.io and similar)

What it gets you: Developer experience comparable to Heroku/Railway/Render, running on EU-only infrastructure. No CLOUD Act exposure. No infrastructure management overhead. GDPR-compliant by architecture.

sota.io deploys your containerized applications on EU infrastructure, with no US parent company exposure, a straightforward DPA, and pricing that doesn't require a fintech procurement approval cycle. It is designed specifically for EU developers who need sovereignty without the Kubernetes overhead.

When EU-native PaaS makes sense:

You are building for regulated EU industries (fintech, healthtech, legaltech)
Your customers ask about data residency in sales conversations
You want to credibly answer GDPR audit questions without legal counsel involvement
You are tired of explaining why "AWS Frankfurt" doesn't fully resolve CLOUD Act questions

The Practical Takeaway: The Market Is Pricing In Sovereignty

The DNB's move to a non-US cloud provider is one data point in a broader pattern:

German sovereign cloud initiative: The BSI (Federal Office for Information Security) and the German government have pushed for C5-certified EU providers and warned explicitly about CLOUD Act risks in public procurement.
French cloud de confiance: The ANSSI (French cybersecurity agency) created the "cloud de confiance" certification, explicitly requiring that providers not be subject to non-EU law enforcement access.
EU AI Office guidance: Draft guidance on GDPR compliance for AI systems explicitly flags US cloud provider CLOUD Act exposure as a risk factor for high-risk AI applications.
EDPB transfer impact assessments: The European Data Protection Board's guidance on transfer impact assessments (TIAs) requires organizations to evaluate CLOUD Act exposure as part of any US cloud provider due diligence.

Central banks do not make infrastructure decisions lightly or quickly. The fact that DNB has already completed this migration means the compliance analysis was done, the legal review was completed, and the business case was approved — months or years before the news became public.

For EU developers building products for regulated industries, the question is not whether EU sovereignty requirements will affect your sales cycle. It is whether you have already addressed them in your infrastructure architecture — or whether you will address them reactively, under customer pressure, during an enterprise deal.

Making the Switch: Migration Considerations

If you are evaluating a move away from AWS EU regions to an EU-native provider, the practical migration checklist includes:

1. Inventory your sub-processor CLOUD Act exposure Map every third-party service your application uses. Flag any with US corporate parents (GitHub, Datadog, Sentry, Cloudflare, Stripe, SendGrid). Each is a potential CLOUD Act exposure point that your DPA must address.

2. Evaluate your EU-native alternatives for each category

Observability: Grafana Cloud EU, Signoz (self-hosted), Uptrace, Checkly (EU)
CI/CD: GitLab CE, Forgejo, Woodpecker CI
Error tracking: GlitchTip, Bugsink, Highlight.io (EU-hosted)
Hosting: sota.io, Hetzner, OVHcloud, Exoscale

3. Update your DPA and sub-processor list EU corporate customers will request your current sub-processor list. Having it ready and accurate is a competitive advantage in enterprise sales cycles.

4. Plan your DNS and CDN strategy If you move compute to EU, ensure your CDN does not reintroduce US CLOUD Act exposure. EU-native CDN options include Bunny.net (Slovenia), KeyCDN (Switzerland), and Fastly EU Edge (separate legal entity considerations apply).

5. Document your sovereignty architecture Regulated industry customers want a one-page sovereignty architecture document they can attach to their own regulatory filing. Preparing this in advance converts a procurement friction point into a sales accelerator.

Conclusion: Central Banks Lead, the Market Follows

The Dutch Central Bank's migration away from AWS is a signal, not just a story. EU cloud sovereignty has moved from a compliance checkbox to an active infrastructure architecture decision at the highest levels of financial regulation.

For EU SaaS developers, the question is strategic: do you build your infrastructure architecture to support sovereignty claims now — when it is a competitive differentiator — or later, when regulated industry customers require it as a qualification threshold?

The tooling exists. EU-native PaaS providers like sota.io, IaaS providers like Hetzner and OVHcloud, and the growing ecosystem of EU-native developer tools mean that "build on EU infrastructure" no longer requires sacrificing developer experience.

The DNB made its infrastructure decision based on regulatory requirements that were already in force. For EU developers, making that decision proactively — before your enterprise sales cycle forces it — is now both technically feasible and commercially sensible.

Deploy on EU infrastructure from day one. sota.io gives you Heroku-level developer experience on EU-sovereign infrastructure — no CLOUD Act exposure, no Kubernetes overhead, GDPR-compliant by default.