European organizations face a problem that most technology vendors would prefer they not think too hard about. The three largest cloud providers, AWS, Microsoft Azure, and Google Cloud, control roughly 70% of the European cloud market. All three are US-headquartered companies subject to US law. And US law, specifically the CLOUD Act, grants federal authorities the power to compel these companies to hand over data regardless of where that data is physically stored, including data belonging to European citizens sitting on servers in Frankfurt or Amsterdam.
This is not a theoretical concern. It is a structural conflict between two legal systems that cannot both be satisfied simultaneously. And it is reshaping how European organizations think about their cloud infrastructure.
What cloud sovereignty actually means
Cloud sovereignty is the principle that an organization retains full control over its data, infrastructure, and operations, free from the jurisdictional reach of foreign governments or the proprietary constraints of any single vendor.
In practice, sovereignty has three dimensions:
Data sovereignty means that the data is subject only to the laws of the jurisdiction where the data owner operates. For a German company, this means German and EU law, not US law. Storing data in an EU data center is necessary but not sufficient. If the cloud provider is a US company, the data remains within reach of US law regardless of its physical location.
Operational sovereignty means that the people and processes managing the infrastructure are under the same legal jurisdiction as the data. A US company operating an EU data center still employs US-jurisdiction management, US-jurisdiction engineering teams, and US-jurisdiction incident response processes. Operational sovereignty requires that the operator itself is not subject to foreign legal compulsion.
Technical sovereignty means that the infrastructure does not depend on proprietary technology that creates lock-in to a single vendor. If your workloads can only run on one provider’s platform, you do not have sovereignty. You have a dependency with a single point of jurisdictional failure.
The regulatory landscape
The regulatory environment in Europe has shifted dramatically. What was once a collection of guidelines and recommendations has become a set of binding regulations with significant penalties.
GDPR and cross-border data transfers
The General Data Protection Regulation does not technically mandate that data remain within the EU. What it requires is that personal data transferred outside the EU receive essentially equivalent protection to that within the EU.
The Schrems II ruling by the Court of Justice of the European Union in July 2020 invalidated the EU-US Privacy Shield framework, finding that US surveillance programs are not limited to what is strictly necessary and constitute disproportionate interference with data protection rights. The ruling affected approximately 5,380 organizations that relied on Privacy Shield for cross-border transfers.
A replacement framework, the EU-US Data Privacy Framework, was adopted in July 2023. It survived its first legal challenge in September 2025. But with FISA Section 702 renewed and expanded in April 2024, many legal experts expect a Schrems III challenge that could invalidate this framework as well.
For organizations that cannot afford the risk of another adequacy decision collapse, the practical response is straightforward: keep personal data on infrastructure operated by companies that are not subject to US jurisdiction.
The CLOUD Act
The Clarifying Lawful Overseas Use of Data Act was enacted on March 23, 2018, resolving a legal dispute that had reached the US Supreme Court. In 2013, the FBI issued a warrant for emails stored on Microsoft’s Dublin datacenter. Microsoft refused to comply. The case went to the Supreme Court but was declared moot after Congress passed the CLOUD Act, which settled the question in the government’s favor.
The law compels US-based technology companies to provide data to federal law enforcement regardless of where that data is stored. It does not matter if the server is in Frankfurt, the customer is German, and the data belongs to German citizens. If the provider is a US company, the data is reachable.
Providers can theoretically move to quash or modify a request if it conflicts with foreign law, but this mechanism is discretionary and rarely exercised. During a hearing in France, Microsoft’s chief legal officer admitted that Microsoft could not rule out being forced to disclose data stored in Europe.
NIS2 directive
The Network and Information Security Directive 2 took effect on October 18, 2024, explicitly covering cloud computing service providers as essential entities. Organizations with 50 or more employees or 10 million EUR in annual turnover operating in 18 critical sectors must comply.
The directive requires supply chain risk management, incident reporting within 24 hours, and business continuity planning. Penalties for essential entities reach up to 10 million EUR or 2% of global annual turnover. Executives face potential management bans and personal fines.
For cloud infrastructure specifically, NIS2 requires organizations to assess and manage risks arising from their cloud dependencies, including the jurisdictional risk of using providers subject to foreign government data access.
DORA
The Digital Operational Resilience Act has applied since January 17, 2025, specifically targeting ICT concentration risk in financial services. ECB supervisory data shows that more than 30% of total outsourcing budgets at significant banks is concentrated with just 10 providers.
In November 2025, the European Supervisory Authorities designated 19 ICT service providers as critical under DORA, including AWS, Microsoft Azure, and Google Cloud, subjecting them to direct EU supervision for the first time. Financial entities must now map their third-party ICT dependencies and conduct concentration risk assessments before entering vendor agreements.
EU Data Act
The EU Data Act, applicable since September 12, 2025, directly addresses cloud switching and portability. It requires cloud providers to eliminate all switching fees by January 12, 2027. Providers must allow customers to switch at any time with a maximum two-month notice period and a 30-day transition period. After switching, the provider must give customers at least 30 days to retrieve their data before deleting it.
The Act covers IaaS, PaaS, and SaaS. Non-compliance penalties reach up to 4% of global annual turnover, matching GDPR fines. For the first time, European law treats the ability to leave a cloud provider not as a business preference but as a legal right.
The sovereignty gap
Despite this regulatory pressure, the market reality has not caught up. European cloud providers’ share of their home market dropped from 29% in 2017 to 15% in 2022 and has plateaued. The big three US hyperscalers continue to grow their European footprint.
The gap exists because sovereignty is not just a legal question. It is also a technical and operational one.
Sovereign cloud offerings from US hyperscalers
All three major US cloud providers now offer “sovereign cloud” variants for the European market. Microsoft has Delos Cloud (a SAP subsidiary operating Azure services in Germany). Google has S3NS (a Thales joint venture that achieved France’s SecNumCloud 3.2 certification). AWS offers Dedicated Local Zones.
These offerings address some aspects of operational sovereignty by placing infrastructure and operations under European entities. But they do not resolve the fundamental jurisdictional problem. The underlying technology, the software supply chain, and ultimately the corporate parent remain under US jurisdiction. As the FISA 702 expansion in April 2024 demonstrated, the scope of US government access is expanding, not contracting.
As Cloudfleet noted in its response to the UK CMA cloud market report, hyperscaler sovereign clouds maintain the same underlying technical dependencies, pricing structures, and vendor lock-in risks as their standard offerings. Adopting one is similar to adopting an entirely new provider, isolated by design.
European alternatives
Native European cloud providers offer genuine jurisdictional sovereignty:
- Hetzner (Germany): Cost-effective compute with NVMe storage, six regions across three continents, GDPR-compliant data centers
- OVHcloud (France): Large-scale European cloud with global presence
- Scaleway (France): Developer-focused cloud with strong European data sovereignty positioning
- Exoscale (Switzerland/Austria): Enterprise cloud with explicit GDPR and data sovereignty focus
The trade-off is that none of these providers offer the breadth of managed services available on AWS, Azure, or GCP. There is no European equivalent of DynamoDB, BigQuery, or Azure Cognitive Services. Organizations choosing European infrastructure must either accept a narrower service catalog or use a platform layer that bridges the gap.
Infrastructure portability: the technical foundation of sovereignty
Sovereignty without portability is fragile. If your workloads are technically locked into a single provider through proprietary APIs, data formats, or service dependencies, then your sovereignty depends on that provider’s continued cooperation. True sovereignty requires the ability to move.
Why portability is hard
Cloud providers design their services to create switching costs. The most visible mechanism is egress fees: AWS charges $0.09 per GB, Azure $0.087, and Google Cloud $0.12 for data leaving their networks. For organizations with terabytes of data, the cost of simply copying data to another provider can run into tens of thousands of dollars.
But egress fees are only the surface. The deeper lock-in comes from proprietary services that have no portable equivalent. An application built on AWS Lambda, DynamoDB, and SQS cannot move to another provider without rewriting significant portions of its architecture. Microsoft licensing practices can make it more expensive to run business software on any cloud other than Azure. Google’s Anthos, while promising multi-cloud management, requires a persistent connection back to Google Cloud.
The UK Competition and Markets Authority documented these dynamics in its 2025 cloud market investigation, finding that less than 1% of businesses switch cloud providers annually, not because they are satisfied but because switching is too difficult.
Kubernetes as a portability layer
Kubernetes has become the de facto standard for workload portability. By abstracting away infrastructure specifics behind a standard API, Kubernetes allows the same workloads to run on any provider that supports it, which today means every major cloud provider and any Linux server.
A Kubernetes Deployment, Service, or Ingress resource works identically whether the cluster runs on AWS, Hetzner, or a rack of servers in your own data center. This is not theoretical portability. Organizations routinely move Kubernetes workloads between providers.
However, Kubernetes alone does not solve the portability problem completely. If your cluster uses AWS-specific load balancers, EBS storage classes, or IAM roles, those dependencies follow you. Portability requires discipline: using standard Kubernetes abstractions, avoiding provider-specific extensions where possible, and choosing open-source databases and tools over managed proprietary services.
The CNCF’s 2023 survey found that organizations run workloads across an average of 2.8 unique clouds. Kubernetes is the primary mechanism enabling this.
Building for portability in practice
Five architectural principles help maintain portability without sacrificing productivity:
Use open-source infrastructure components. PostgreSQL instead of Aurora. Redis instead of ElastiCache. MinIO or Ceph instead of S3 for private object storage. Open-source components can run on any infrastructure. Managed proprietary services create dependencies that are expensive to unwind.
Use Kubernetes as your workload layer. Kubernetes provides the abstraction between your application and the infrastructure. Standard Kubernetes APIs (Deployments, Services, Ingress, PersistentVolumeClaims) are portable across every provider. Avoid Kubernetes distributions that add proprietary extensions.
Keep data portable. Design data storage so that data can be exported in standard formats. Use backup tools that work across providers. Consider where your primary data store runs and whether it can move.
Plan for multi-cloud from the start. Even if you deploy on a single provider today, architect your systems so they do not depend on provider-specific services. This is cheaper than retrofitting portability later.
Choose vendors that do not create lock-in. Evaluate not just what a vendor offers but what it takes to leave. The EU Data Act now makes this a legal requirement, but the technical reality still varies widely between providers.
How Cloudfleet approaches sovereignty
Cloudfleet is a managed Kubernetes platform designed from the ground up for multi-cloud and hybrid deployments, with European sovereignty as a core architectural principle rather than an aftermarket add-on.
European jurisdiction. Cloudfleet GmbH is incorporated in Berlin, Germany (HRB 279792 B, Amtsgericht Berlin-Charlottenburg). It is subject to German and EU law. It is not subject to the US CLOUD Act. US authorities cannot compel Cloudfleet to hand over customer data because Cloudfleet is not a US company and does not operate under US jurisdiction.
Infrastructure choice. Cloudfleet supports running workloads on European cloud providers including Hetzner, OVHcloud, Scaleway, and Exoscale, as well as on-premises infrastructure. A single Cloudfleet cluster can span multiple providers and locations, so you can keep workloads on European infrastructure while retaining the flexibility to use other providers for specific requirements.
No proprietary lock-in. Cloudfleet runs CNCF-conformant Kubernetes. There are no proprietary abstractions, no custom resource types that only work on Cloudfleet, and no vendor-specific APIs. Your Helm charts, manifests, and CI/CD pipelines work without modification. If you decide to leave Cloudfleet, your workloads run on any standard Kubernetes platform.
Technical sovereignty features. Workload Identity Federation provides secure, keyless access to cloud APIs without storing static credentials. An encrypted WireGuard overlay network connects all nodes across all environments. Self-managed nodes can be added to a cluster with a single CLI command on any Linux machine, supporting bare metal, Proxmox VE, and other virtualization platforms.
Transparent pricing. The Basic tier is free for clusters up to 24 vCPUs. The Pro tier is $79/month with a 99.95% uptime SLA. There are no per-core licensing fees, no mandatory add-on subscriptions, and no multi-year commitments. Costs are predictable and proportional to usage.
Sovereignty evaluation checklist
When evaluating any cloud platform or provider for sovereignty, consider these questions:
Jurisdiction
- Where is the provider legally incorporated?
- Is the provider or its parent company subject to the US CLOUD Act or equivalent foreign data access laws?
- Can the provider guarantee that customer data will not be disclosed to foreign government agencies?
Data residency
- Can you restrict all data (including metadata, logs, and telemetry) to EU-based infrastructure?
- Does the provider require outbound connectivity to non-EU services for management or control plane functions?
- Who has physical and logical access to the infrastructure?
Portability
- Can you export your data and workloads in standard formats?
- Does the platform use open standards (CNCF-conformant Kubernetes, OCI containers) or proprietary abstractions?
- What are the egress fees for moving data to another provider?
- How long would it take to migrate your workloads to a different platform?
Operational independence
- Can the platform operate if the provider experiences a service disruption?
- Are you dependent on the provider for critical infrastructure functions (DNS, identity, networking)?
- Do you have access to the underlying infrastructure for audit and compliance purposes?
Regulatory compliance
- Does the provider offer GDPR-compliant data processing agreements?
- Can the infrastructure meet NIS2 supply chain risk management requirements?
- For financial services: does the architecture support DORA concentration risk assessments?
The road ahead
The sovereign cloud market is growing rapidly. Gartner forecasts worldwide sovereign cloud IaaS spending at $80 billion in 2026, a 35.6% increase from 2025. Europe is projected to surpass North America in sovereign cloud spending in 2027, with 83% growth expected in 2026.
Initiatives like Gaia-X, France’s SecNumCloud certification, and Germany’s Deutsche Verwaltungscloud are building the institutional frameworks for a sovereign European cloud ecosystem. The EU Data Act and DORA are creating the legal foundations for provider portability and concentration risk management.
But regulation alone will not solve the problem. Cloud sovereignty is ultimately an architectural decision. It requires choosing infrastructure, platforms, and tools that keep your organization in control, able to move workloads between providers, free from foreign jurisdictional exposure, and independent of any single vendor’s proprietary technology stack.
The organizations that get this right will have a structural advantage: the ability to comply with current and future regulations without redesigning their infrastructure, the flexibility to optimize costs across providers, and the confidence that their data is governed by the laws they expect.
