EU Cloud Sovereignty for Indie Devs: Why "EU Servers" Is Not Enough

In January 2026, AWS launched the AWS European Sovereign Cloud — a dedicated infrastructure offering marketed specifically at EU customers who need "data to remain in the EU." The timing was not accidental. Two weeks earlier, the European Data Protection Board had published updated guidance on international data transfers. Enterprise demand for sovereignty has never been louder.

But here is the part that almost nobody talks about: EU servers do not equal EU sovereignty. AWS's "Sovereign Cloud" is still operated by Amazon Web Services, Inc. — a US company incorporated in Delaware. And that single fact changes everything for your legal exposure under the CLOUD Act.

This post is for indie developers and small teams building GDPR-regulated products. The platforms you use every day — Railway, Render, Vercel, and yes, even AWS's "Sovereign Cloud" — may have EU data centers. They cannot give you genuine data sovereignty as long as they are US-headquartered companies.

What the CLOUD Act Actually Says

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 2018) was passed to resolve jurisdictional conflicts between US law enforcement and cloud providers operating globally. The core provision is blunt:

A US person or entity that provides electronic communication services or remote computing services must produce stored data to US law enforcement, regardless of where that data is stored.

Read that again. Regardless of where the data is stored.

This means that if you deploy your SaaS on Railway (US-headquartered) and store your EU users' personal data in Railway's Frankfurt region, the US Department of Justice can compel Railway to hand over that data — without notifying you, and without notifying your users.

Railway cannot legally refuse. Their Frankfurt servers are irrelevant to this analysis.

The same applies to:

• Render (San Francisco, CA)
• Vercel (San Francisco, CA)
• Heroku / Salesforce (San Francisco, CA)
• AWS, GCP, Azure (all US-incorporated parent entities)
• Fly.io (Chicago, IL)

Every US-incorporated cloud platform is CLOUD Act-subject, regardless of where their data centers sit.

The Schrems II Layer

If the CLOUD Act sounds alarming, add the Schrems II ruling on top.

In July 2020, the European Court of Justice invalidated the EU-US Privacy Shield framework in Data Protection Commissioner v. Facebook Ireland (Schrems II). The ruling found that US surveillance law — specifically FISA Section 702 and Executive Order 12333 — gives US intelligence agencies access to personal data in a way that is incompatible with EU fundamental rights standards.

The fallback mechanism — Standard Contractual Clauses (SCCs) — was preserved but conditionally. You can use SCCs, but only if you conduct a Transfer Impact Assessment (TIA) and conclude that the legal framework in the destination country offers equivalent protection. For US cloud providers, that TIA will reveal the CLOUD Act and FISA exposure. You cannot honestly conclude those risks away.

This is not theoretical. In 2022, the Austrian Data Protection Authority ruled that Google Analytics violated GDPR because data was transferred to Google LLC (US) and therefore subject to US surveillance law. In 2023, the French CNIL issued similar findings. EU regulators have teeth here.

For indie developers: you probably cannot afford a lawyer to write a TIA. And even if you could, you cannot make a US cloud provider CLOUD Act-immune.

The AWS European Sovereign Cloud Is Not the Answer

AWS launched its European Sovereign Cloud in Germany in January 2026 with promises of "operational independence" from non-EU AWS teams. It is a serious product with genuine engineering behind it. Enterprise banks and healthcare systems may legitimately evaluate it.

But AWS explicitly states in its documentation that the Sovereign Cloud operates under Amazon Web Services EMEA SARL (Luxembourg) — a subsidiary of Amazon.com, Inc. (Seattle, WA). Luxembourg-incorporated subsidiary, US ultimate parent.

That parent-subsidiary structure means a US court can potentially pierce through to the subsidiary. Legal scholars debate how far CLOUD Act reach extends through subsidiary structures, but the answer is not a clean "you are fully protected." Enterprise legal teams ask these questions for a reason.

For indie developers building products without a legal department, the practical answer is: do not create the exposure in the first place.

What Real EU Cloud Sovereignty Looks Like

Genuine EU cloud sovereignty requires three conditions, all of which must hold simultaneously:

1. EU-incorporated entity in the ownership chain — no US parent. The company operating your infrastructure must be incorporated under EU law, with no US ultimate parent company. This is the CLOUD Act immunity condition.

2. Data stored exclusively in the EU. Servers in the EU — but this alone is not sufficient, as established above. It is a necessary but not sufficient condition.

3. Data Processing Agreement available without a sales call. A serious GDPR-compliant provider makes the DPA available in their documentation. If you need to talk to a sales representative before accessing the DPA, you are not the intended customer.

A fourth practical condition applies specifically to indie developers: flat, predictable pricing. Sovereignty should not cost enterprise pricing. You should not need to buy a minimum commitment to access EU-compliant infrastructure.

A Quick Sovereignty Checklist

Before you sign up for any hosting platform, run this checklist:

For Railway: US-incorporated, EU region optional. Fails condition 1. For Vercel: US-incorporated, no guaranteed EU-only data path. Fails conditions 1 and 2. For AWS Sovereign Cloud: EU subsidiary, US parent. Condition 1 is ambiguous.

The sota.io Position

sota.io is an EU-native PaaS built for this exact scenario. It deploys your apps to Germany, is incorporated under EU law, and has no US parent entity in the ownership chain.

The practical implications:

• CLOUD Act exposure: none. No US entity to compel.
• Data residency: Germany by default. Not as a configuration option — as the default.
• DPA: available in documentation. No sales call required.
• Pricing: flat. Free tier for solo projects, EUR 9/month for teams.

Deployment is a single command:

# Install CLI
npm install -g @sota-io/cli

# Deploy — that's it
sota deploy

Framework detection handles Node.js, Next.js, Bun, and Python automatically. PostgreSQL 17 is included with every project. No separate database provisioning.

Why This Matters More in 2026 Than It Did in 2022

Three things have shifted the calculus for indie developers specifically:

Regulatory enforcement is accelerating. The EU AI Act, DORA (Digital Operational Resilience Act), and NIS2 have all come into force or enforcement in 2024–2026. Each of these regulations implicitly or explicitly requires traceability of where your data lives and who can access it.

Enterprise clients are asking. If you build B2B SaaS for European mid-market or enterprise clients, you will be sent a vendor questionnaire. "Where is your data hosted?" is question 3. "Is the hosting provider EU-incorporated?" is question 4.

US-EU data transfer frameworks remain legally fragile. The current EU-US Data Privacy Framework (DPF, 2023) is already under challenge at the ECJ. Schrems himself has filed a challenge. Banking your compliance on a framework that may be invalidated for the third time in a decade is not a risk management strategy.

The cleanest approach is to avoid the exposure entirely. Use EU-incorporated infrastructure. Remove the US company from your data chain.

sota.io is an EU-native deployment platform — servers in Germany, incorporated in the EU, no US parent company. Deploy your first app free, no credit card required.

See also: Why developers are leaving Vercel for EU-native hosting · Railway alternative: EU hosting guide