AWS European Sovereign Cloud: Why a Separate German Region Still Can't Close the CLOUD Act Gap

On January 15, 2026, AWS launched a cloud that is legally not AWS — at least on paper. The AWS European Sovereign Cloud went generally available in Brandenburg, Germany, as a physically and logically separate partition from every other AWS Region, operated by a new German company, staffed exclusively by EU residents, backed by a stated €7.8 billion investment, and already slated to expand to Belgium, the Netherlands, and Portugal. Ninety AWS services were available on day one, behind independent root certificates, independent networking, and an independent Security Operations Center.

If you buy infrastructure for a living, that should trigger two reactions. The first is genuine: this is the most concrete sovereignty product a US hyperscaler has ever shipped. The second is the question the press release does not answer: does any of that change which country's courts can compel the data?

The short answer is no — not at the layer that matters for a regulated buyer. The Sovereign Cloud closes the technical-isolation half of sovereignty while leaving the corporate-jurisdiction half exactly where it was. This post puts a scorecard on both halves and shows what a self-hosted PaaS on an EU-headquartered provider actually buys instead.

The Sovereign Cloud SKU Has Shipped — And It Is Not a Rebrand​

AWS first previewed the European Sovereign Cloud in October 2023 and went GA on January 15, 2026. The facts that are not in dispute:

• Location and separation. The first Region lives in Brandenburg, the state surrounding Berlin, and is entirely located within the EU. AWS describes it as physically and logically separate from all other AWS Regions — separate data centers, separate networking, separate control plane partition. It is not an eu-central-1 availability zone with a new label.
• Services. About 90 AWS services were available at launch, with the remainder of the portfolio to follow under the same partition. For comparison, a standard commercial Region carries 200+ services, so the sovereign partition starts as a large subset, not full parity.
• Legal entity. AWS created a new German parent company, AWS European Sovereign Cloud GmbH, incorporated in Germany to operate the sovereign cloud. Governance includes an advisory board with exclusively EU citizens, including at least one member with no ties to Amazon, and a dedicated SOC.
• People. The cloud is operated exclusively by EU-resident employees. AWS's own framing emphasizes local root certificates, locally sourced hardware supply chain options, and EU-only customer support.
• Money and footprint. Amazon plans to invest more than €7.8 billion in the sovereign cloud in Germany, supporting an average of 2,800 full-time equivalent jobs annually. Expansion zones in Belgium, the Netherlands, and Portugal were announced alongside the GA.
• Who it is for. The messaging targets exactly the buyers who have been most hesitant about US hyperscalers in Europe: government, healthcare, financial services, and defense workloads that cannot accept US-jurisdiction risk.

Credit where it is due: this is not the usual "your data stays in Frankfurt" checkbox. A separate legal entity, separate staff, separate keys, and separate networking is a materially larger commitment than a data-residency toggle in a console. It addresses real concerns about operational autonomy, metadata residency, and who can push a config change at 3 a.m.

It does not address the concern written into US federal law.

What AWS Actually Built: The Technical-Isolation Half​

Think of sovereignty as two independent walls that both have to hold. The first wall is technical isolation: can anyone outside the EU — including the vendor's own staff in Seattle — access, move, or reconfigure the data without going through EU-controlled gates?

On that wall, the European Sovereign Cloud makes genuine progress over a standard EU Region:

• Physical isolation. Data centers, power, and network fabric dedicated to the sovereign partition, not shared with commercial Regions.
• Logical isolation. Independent root certificates, dedicated networking, and an independent control plane. A compromise or misconfiguration in eu-central-1 does not transitively grant access to the sovereign partition.
• Operational isolation. EU-resident-only operators, an EU-based SOC, and support workflows that do not route through US staff. AWS's whitepaper adds controls for law-enforcement access requests and metadata handling specific to the sovereign partition.
• Supply-chain isolation. Infrastructure sourced with European-provider options where available, reducing non-EU critical dependencies in the hardware and facility chain.

For a buyer whose primary anxiety is "I do not want my data replicated to Virginia, and I do not want a US employee to be able to open a support ticket and see it," these controls are meaningful. They raise the bar for accidental exposure, insider access, and availability coupling to other Regions.

That is why the launch landed as credible news rather than marketing theater. It also explains why it is not sufficient for the buyers who need the second wall to hold.

What It Deliberately Did Not Fix: The Corporate-Jurisdiction Half​

The second wall is corporate jurisdiction: which country's courts can order the company that operates the cloud to hand over data, regardless of where the servers sit?

The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, codified at 18 U.S.C. §2703) answers that question bluntly. It permits US courts to compel a US-incorporated provider to disclose data in its possession, custody, or control — even if that data is stored outside the United States. The test is jurisdiction over the corporation, not GPS coordinates of the disk.

AWS's European Sovereign Cloud GmbH is a subsidiary of Amazon.com, Inc., a US corporation headquartered in Seattle. Creating a German GmbH with an EU-only staff does not sever that corporate chain. A valid CLOUD Act order served on the US parent can still reach data the subsidiary controls if the parent has the legal ability to compel its subsidiary — which, by definition, it does.

Three consequences follow that no architecture diagram can paper over:

• Contractual safeguards do not immunize. The European Data Protection Board applies a two-step GDPR test: any disclosure must have a valid legal basis under Article 6 and an Article 49 derogation. A promise that "we will not disclose" does not satisfy either step when disclosure is compelled by US law. The provider must comply or face US consequences; the EU customer's DPA then has grounds to find protections insufficient under Schrems II.
• The "separate entity" argument has been tested. The CLOUD Act provides only a narrow, multi-factor path to quash a warrant on comity grounds (18 U.S.C. §2703(h)), weighed case by case. No hyperscaler has obtained a blanket ruling that a foreign subsidiary's data is categorically out of reach. Relying on that outcome is a legal bet, not a control.
• Residency and jurisdiction are different properties. Storing data in Brandenburg satisfies data residency. It does not satisfy legal jurisdiction. An EU-headquartered provider like Hetzner Online GmbH, OVHcloud SAS, or Scaleway SAS sits outside CLOUD Act reach because the operator itself is not a US person. An AWS region in Germany does not, because the operator ultimately is.

AWS is candid about this boundary in its own materials. Its spokespeople note that customers can encrypt data in the sovereign cloud and that AWS employees cannot access or pass over encrypted data — which is true and valuable, but shifts the trust anchor from "the operator is outside US jurisdiction" to "the operator cannot technically comply even if ordered, because it does not hold the keys." That is a meaningful mitigation, but it is not the same claim as jurisdictional immunity. Hold your own keys (BYOK/HYOK with EU-only key management) and the mitigation is strong. Leave key management with the provider and it is not.

The Scorecard That Makes It Visible: SEAL 0–4​

In September 2025 the European Commission published its Cloud Sovereignty Framework, and in 2026 that framework started showing up in real procurement language. Its core is the Sovereignty Effectiveness Assurance Level (SEAL) — a weighted score from 0 to 4 across eight sovereignty objectives:

SOV-1 legal jurisdiction, SOV-2 data residency, SOV-3 supply-chain provenance, SOV-4 audit and transparency rights, SOV-5 EU key management, SOV-6 open-source and reversibility, SOV-7 NIS2 and operational compliance, SOV-8 GDPR and incident-response posture. SEAL-0 is no meaningful sovereignty, SEAL-4 is full digital sovereignty with no critical non-EU dependencies.

The framework turns the distinction from opinion into a score:

• Standard EU Region (e.g., AWS eu-central-1): Strong on residency (SOV-2), weak on jurisdiction (SOV-1), mixed elsewhere. Typical weighted outcome: SEAL-1 — not procurement-grade for regulated workloads.
• AWS European Sovereign Cloud: Strong on residency, autonomy, and supply-chain; better on audit and key management than a standard Region. But SOV-1 still scores low because the ultimate parent remains a US corporation. Typical outcome: SEAL-2 — "EU law applicable, but material non-EU dependencies remain."
• EU-native bare metal (Hetzner, OVHcloud, Scaleway) with self-hosted PaaS: SOV-1 passes by incorporation, SOV-2 by location, and SOV-3–SOV-8 depend on tenant config — but the ceiling is structurally higher. With EU-only key management and no US parent, a well-configured fleet reaches SEAL-3 or SEAL-4. ANSSI's SecNumCloud 3.2 visa — GA for OVHcloud in June 2026 with ~360 controls and explicit immunity to extraterritorial law — is the concrete example of what certifying that ceiling actually requires.

The signal is already visible. In October 2025 the Commission opened a €180 million tender scored on SEAL; reporting noted US hyperscalers were excluded as direct operators on SOV-1 — not on residency, price, or service breadth. Weeks later, the International Criminal Court confirmed it was moving off a US provider's stack onto open-source alternatives under EU jurisdiction for the same reason.

Side by Side: What Each Model Actually Buys You​

The table below scores three models a European team actually chooses between in 2026 — a standard commercial EU Region, the AWS European Sovereign Cloud, and a self-hosted PaaS (such as bex on Hetzner or OVHcloud) — across the six questions a regulated buyer asks before signing. Shading is SEAL-informed, not vendor-provided.

Two trade-offs deserve explicit framing.

First, ecosystem for immunity. The sovereign partition trades service breadth for operational isolation; a self-hosted fleet trades managed-service breadth for jurisdictional immunity. If your workload needs Bedrock or SageMaker, the self-hosted path does not offer a drop-in — it offers a different place to run the open equivalent (vLLM, llm-d, Gateway API) on hardware you own.

Second, operational burden for autonomy. A sovereign SKU still sells you an operated service. A bex-on-Hetzner fleet sells you the machines and the Cluster API automation to operate them yourself — cheaper per tenant at scale and immune to a vendor repricing, but requiring your team to own upgrades, backups, and incident response.

Who Should Buy Which — An Honest Decision Framework​

Not every European workload needs SEAL-4, and paying for it when you do not needs it is waste. The right question is not "is AWS sovereign?" but "which wall does my threat model actually require?"

Buy the AWS European Sovereign Cloud if: your regulator or customer requires EU data and operational residency with strong audit rights, your team values the deepest AWS service integration available under EU confinement, and your legal analysis concludes that residency plus customer-held keys (HYOK with EU-only custody) is a sufficient mitigation for CLOUD Act risk for your data classification. Many GDPR-sensitive SaaS workloads land here — residency satisfies the DPA, and the service breadth outweighs the residual jurisdiction risk once keys are held locally.

Buy the standard EU Region if: you are a general builder with no regulated-data exposure, no procurement SEAL threshold to clear, and no customer contract that names jurisdiction. The price is lower, the service surface is wider, and the CLOUD Act gap is a risk you have consciously accepted rather than one you need to close.

Self-host on EU-native bare metal (bex on Hetzner/OVHcloud) if: you operate in government, healthcare, finance, or defense; you bid on EU tenders that score SEAL-2+ on SOV-1; or your customer contracts explicitly require that no US person in the corporate chain can be compelled to disclose the data — not "cannot technically access without keys" but "cannot be legally ordered to try." The same buyers who triggered the €180 million procurement and the ICC migration fall in this bucket.

Four questions settle it faster than any whitepaper:

1. Does a regulator, tender, or customer contract name legal jurisdiction — not just data location — as a scored or pass/fail requirement? If yes, SEAL-1 will not clear it and SEAL-2 is contested ground.
2. Who holds the encryption keys, and where? EU-only HYOK narrows the CLOUD Act exposure on any model; provider-held keys do not.
3. What is your recourse if the vendor reprices, deprecates, or restricts capacity? A German GmbH that depends on a US parent's roadmap is still a subsidiary, not a sovereign.
4. What do you lose by trading ecosystem for immunity — and can the open equivalents run on hardware you already budget for?

The AWS European Sovereign Cloud is a real step forward on the first wall. It puts EU residency, EU operations, and EU supply-chain choices behind a partition that did not exist a year ago. For many teams, that is enough. For the teams whose sovereignty requirement is jurisdictional rather than geographic, the honest label for what AWS built is EU residency under US jurisdiction with strong technical mitigations — a narrower claim than "sovereign" and a claim a SEAL audit already knows how to score.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. It runs on EU-headquartered bare metal (Hetzner, OVHcloud) where the operator itself sits outside CLOUD Act reach, not just the data center's postcode. Star the repo on GitHub or deploy your first app today.