GDPR and data residency on AWS: why eu-west-3 isn't always enough

“We host on eu-west-3, in Paris, so we’re GDPR compliant” is the line we hear most often at the start of an audit — and it’s both true and incomplete. True because the Paris region meets GDPR’s data residency requirements. Incomplete because data residency and legal sovereignty are two different things — and the confusion between them has become a real business topic since AWS launched the AWS European Sovereign Cloud on January 15, 2026.

This article breaks down what eu-west-3 actually covers, what AWS’s new sovereign cloud does (and doesn’t) provide, where SecNumCloud sits in that hierarchy, and — most importantly — which SMBs actually need to look beyond the Paris region.

eu-west-3: what it covers, and what it doesn’t

The AWS Paris region (eu-west-3), operational since late 2017 with three availability zones, hosts your data physically in Île-de-France as long as you don’t enable cross-region replication. That satisfies GDPR’s requirement of processing within the EU, and AWS is certified under the EU-US Data Privacy Framework (DPF) adopted in July 2023, which legally governs the rare transatlantic flows (technical support, billing).

What it doesn’t resolve: AWS remains a US-incorporated company, subject to the CLOUD Act (2018), which lets US law enforcement compel access to data held by a US company — even when that data physically sits in France. The DPF legally protects transfers of personal data to the US, but it doesn’t neutralize CLOUD Act exposure for data hosted in the EU by a subsidiary of a US group. The European Data Protection Board (EDPB) has repeated this distinction more than once: geographic residency and jurisdictional immunity are not the same guarantee.

For the vast majority of B2B SMBs, that remains an acceptable risk level — the odds of a CLOUD Act request specifically targeting a French SMB with no US ties are low, and the CNIL doesn’t require it as a baseline GDPR compliance criterion. But two categories of companies can no longer ignore it: those processing sensitive health or defense data, and those responding to public tenders or RFPs that contractually require a sovereignty guarantee.

The new entrant: AWS European Sovereign Cloud

On January 15, 2026, AWS launched the AWS European Sovereign Cloud (ESC), an infrastructure described as “physically and logically separate” from standard AWS regions. Its first region, eusc-de-east-1, is located in Brandenburg, Germany, with two availability zones at launch.

What actually changes compared to eu-west-3:

• A dedicated legal entity. ESC is operated by a new German-incorporated company (GmbH), with three local subsidiaries, led by European citizens (Stéphane Israël heading operations, Stefan Höchbauer as managing director), and overseen by an advisory board that includes two independent European members.
• EU-resident-only staffing. Only EU residents can operate the infrastructure and access source code replicas for exceptional maintenance — with no critical dependency on non-EU infrastructure.
• Continuity even if communications with the outside world are disrupted, according to AWS — a scenario designed for government agencies and OIVs (critical infrastructure operators).
• A large announced investment: €7.8bn in Germany, roughly 2,800 FTE jobs, and an extension of “sovereign Local Zones” into Belgium, the Netherlands and Portugal.

But ESC remains an Amazon subsidiary, with a capital ownership chain that ultimately traces back to the US — which, per most legal analyses published since launch, doesn’t fully neutralize CLOUD Act exposure in the strict sense. It’s a genuine step forward in governance and residency, not full immunity.

The other very concrete limitation for any SMB evaluating a migration: the service catalog is still narrow. As of now, ESC offers roughly 90 services versus 240+ on standard commercial regions. Missing pieces include: GPU instances (none at all, which rules out heavy AI training or inference), IAM Identity Center (planned Q1 2026), CloudFront (planned end of 2026), CodeDeploy (Q2 2026), and the CodeCommit/CodeBuild/CodePipeline chain (Q1 2027). Bedrock is available but limited to Amazon Nova Lite and Nova Pro models, without managed RAG or fine-tuning at this time. There’s no Free Tier, and the observed premium on common services runs around 10 to 15% versus eu-central-1 (Frankfurt).

SecNumCloud: the real sovereignty floor

If your requirement is sovereignty in the strict sense — immunity from extraterritorial law, not just EU residency — the reference framework that matters in France is SecNumCloud, ANSSI’s qualification. Among other things, it requires the provider’s capital to be majority-owned by European entities, which effectively excludes subsidiaries of US groups, ESC included. As of 2026, only three providers hold SecNumCloud qualification for general-purpose public cloud offerings: OVHcloud, 3DS Outscale, and Cloud Temple.

The trade-off: an even narrower service catalog than ESC, a smaller tooling and skills ecosystem than AWS’s, and for many SMBs, a migration or hybrid architecture that costs more to build and maintain than actual compliance requires. SecNumCloud is only mandatory for certain OIVs/OSEs (operators of vital importance / essential services) and for public tenders that explicitly require it in their specifications — not for a standard B2B SMB, even one handling health data broadly speaking (worth distinguishing from HDS health-data hosting, which has its own, less strict framework).

The decision framework for an SMB

Three questions, in order:

1. Does a contract or regulation explicitly require SecNumCloud or a CLOUD Act immunity clause? A public tender with that clause, an OIV/OSE status notified by ANSSI, a contractual requirement from a major public sector client. If yes → SecNumCloud, and it’s a full architecture project, not a region choice.
2. Do you process data sensitive enough to justify stronger governance without hitting a regulatory obligation? Large-scale health data, government-related data, sensitive sectors (defense, critical energy). If yes → evaluate ESC, accepting the 10-15% premium and the reduced service catalog — and check service by service that what you need (GPU, CloudFront, managed CI/CD) is already available before committing.
3. Neither applies? That’s the case for the large majority of the B2B, SaaS and e-commerce SMBs we audit. eu-west-3 + client-side encryption + Data Privacy Framework remains the right cost/compliance trade-off. Adding a sovereignty layer without a real obligation means paying a recurring premium and operational complexity for a residual risk that neither the CNIL nor your customers are asking you to cover.

One point often missed in this discussion: client-managed encryption (KMS with keys you control, or application-level encryption before writes) reduces actual exposure far more effectively, and at near-zero cost, than a region change. A CLOUD Act request that obtains encrypted data without the keys obtains nothing usable.

What we actually recommend

• Document the residency/sovereignty distinction in your GDPR records of processing. Many CNIL audits or client due-diligence questionnaires now ask the question explicitly since ESC’s high-profile launch — better to have the answer written down than to improvise it.
• Encrypt genuinely sensitive data client-side, regardless of the chosen region — it’s the measure with the best protection-to-cost ratio.
• Don’t migrate to ESC out of caution. The incomplete service catalog (no GPU, no CloudFront before end of 2026) makes a premature migration costly in complexity for a partial legal benefit.
• If an RFP requires SecNumCloud, scope it during the response phase, not after: a hybrid AWS + SecNumCloud architecture that isolates only the regulated data is often more realistic than a full migration.

Our Architecture & DevSecOps audit systematically includes a review of your data residency and regulatory exposure mapping — useful before responding to a tender or deciding on a European expansion.

Conclusion

The launch of AWS European Sovereign Cloud changes the conversation around cloud sovereignty in Europe, but it doesn’t change the math for most SMBs: eu-west-3 remains GDPR-compliant, the CLOUD Act remains a theoretical risk for a company with no direct US ties, and SecNumCloud remains reserved for a specific regulatory scope. The real question isn’t “should we migrate to sovereign infrastructure,” but “what in my data would justify paying the premium and complexity of moving off standard AWS” — and for the vast majority, the answer fits in one line: nothing, as long as client-side encryption is in place.