The AWS European Sovereign Cloud went generally available in January 2026, with its first region located in Brandenburg, Germany, built as infrastructure that is physically and logically separate from the rest of AWS and operated exclusively by EU residents located in the EU, covering day-to-day operations, technical support, and customer service. The pitch to regulated European organisations was always clear: hyperscaler capability without the data residency and operational autonomy compromises that come with a globally operated cloud. Two launches this month show what it looks like when familiar third-party tooling actually shows up on that infrastructure.

Two vendors, two different gaps closed

Check Point announced on July 1 that its Cloud Firewall is now available on the AWS European Sovereign Cloud, letting customers run network security for their most sensitive workloads entirely within the EU boundary rather than routing security policy enforcement through infrastructure outside it.

Rubrik followed on July 8 with Rubrik Security Cloud, bringing immutable, architecture-native backup, agentic AI-assisted threat detection, sensitive data discovery, and rapid recovery to the sovereign region. For an EU public sector body or a regulated bank, this answers a question that data residency debates often skip past: sovereignty is not just about where production data sits, it is also about where your backups, your recovery point objectives, and your incident response tooling live. A workload that is sovereign in production but backed up to infrastructure outside the boundary has not actually solved the problem.

Why this is more than a checkbox feature

Both vendors are explicit that their offerings target BSI C5, the German Federal Office for Information Security’s cloud compliance criteria catalogue, alongside DORA and NIS2. That is a deliberate signal to the audience that actually needs this: banks and financial infrastructure providers under DORA’s ICT risk management and third-party concentration requirements, and the expanding list of NIS2-covered sectors that now includes public administration, healthcare, and utilities alongside the original critical infrastructure scope.

The practical effect is that an organisation evaluating AWS for a workload it previously assumed had to stay on a domestic or EU-only provider now has a narrower list of missing pieces. Network security and backup and recovery were two of the more obvious gaps, since neither is optional and both directly touch the sovereignty boundary. As more vendors follow this pattern, the argument for staying off major hyperscalers purely on data residency grounds gets harder to sustain, though it does not remove the separate, ongoing question of US legal jurisdiction over the parent company that the EU’s Cloud and AI Development Act discussions are still wrestling with.

What to check before you commit

A sovereign region is not a magic override for every compliance question. Confirm which of your specific services and regions are actually part of the sovereign boundary rather than assuming the whole AWS catalogue is covered, verify how each partner’s control plane and support access is scoped, and check whether your specific regulator’s guidance treats a US-headquartered provider’s EU sovereign region as fully equivalent to an EU-domiciled provider for your particular use case. DORA and NIS2 obligations around third-party risk assessments do not disappear just because the infrastructure is labelled sovereign.

If your organisation is evaluating whether the AWS European Sovereign Cloud, or a comparable sovereign offering, actually satisfies your regulatory obligations, or you need help mapping which of your workloads could move there today, contact Excello Digital. We help European organisations translate sovereignty requirements into concrete architecture decisions instead of marketing claims.