The three major cloud providers now all offer some form of sovereign cloud capability for European organizations. If you are a CTO or CIO responsible for cloud architecture in a regulated industry, this comparison is for you: what each provider actually delivers on sovereignty, where the approaches differ, and what questions to ask before you commit to a direction.
The marketing materials from each provider will tell you that your data stays in Europe and that you meet your compliance requirements. That is true in different ways for different architectures. Understanding what is behind each claim is the architectural decision, not the vendor selection itself.
The difference between residency and sovereignty
Before comparing providers, the distinction between data residency and actual sovereignty matters and is frequently blurred in vendor materials.
Data residency means your data is stored and processed within a geographic boundary. Every major cloud provider has offered European residency for years. You can deploy in Frankfurt, Amsterdam, or Stockholm and your data stays physically within the EU. This is the baseline, not the differentiator.
Sovereignty adds a legal dimension. The question is not only where your data is stored, but who has legal authority over it and under what conditions third parties can access it. The United States CLOUD Act, enacted in 2018, allows US law enforcement to compel American cloud providers to disclose data stored anywhere in the world, regardless of where that data physically resides. European data in a Frankfurt datacenter, operated by a US company, remains subject to that authority.
Sovereign cloud, in its full meaning, addresses both dimensions: physical location and legal jurisdiction. The three major providers have taken genuinely different architectural approaches to each.
AWS: The fully independent entity model
In January 2026, AWS launched the AWS European Sovereign Cloud, with its first region in Brandenburg, Germany. This is the most architecturally distinct of the three approaches.
The AWS European Sovereign Cloud operates as a legally separate entity from Amazon Web Services, Inc. The managing directors are EU residents. The board includes EU citizens, among them two independent third-party representatives. All operational staff must be European citizens. There are no critical dependencies on non-EU infrastructure. The region is physically and logically separate from all other AWS regions and is designed to continue operating independently even if connectivity to the rest of the world is disrupted.
Amazon invested more than 7.8 billion euros in the first German region and announced expansion to Belgium, the Netherlands, and Portugal.
The practical implication for CTOs: if your sovereignty requirement is the strictest possible interpretation, operational independence from US legal authority, AWS ESC currently delivers the most complete structural answer. The trade-off is real: not all AWS services are yet available in the sovereign cloud, and you are building within a newer, more limited environment compared to standard AWS regions. Service availability will expand over time, but today it is a constrained set.
For organizations in sectors where regulators are beginning to specify operational independence requirements, not just data residency, the AWS ESC model is worth examining carefully. It was built to satisfy that interpretation.
Azure: The hybrid boundary model
Microsoft’s approach to sovereignty is structurally different. Rather than building a separate legal entity, Microsoft has pursued two parallel tracks: the EU Data Boundary for public cloud workloads, and a Sovereign Private Cloud option for organizations needing on-premises or air-gapped deployments.
The EU Data Boundary, completed in February 2025, means that customer data for Microsoft 365, Dynamics 365, Power Platform, and most Azure services is stored and processed within the EU and European Free Trade Association. Microsoft has published detailed documentation and transparency reports on government data requests, making this auditable.
In June 2025, Microsoft announced the Sovereign Private Cloud: a combination of Azure Local and Microsoft 365 Local that allows organizations to run Microsoft workloads entirely within their own premises or data centers, with no connectivity to Microsoft’s public cloud if required. France’s Bleu and Germany’s Delos Cloud are operational examples of this model, where national entities partner with Microsoft to deliver services under local governance and legal structures.
For CTOs, the Azure model offers more flexibility but also more architectural decisions. You can choose between fully managed EU-boundary public cloud, hybrid configurations, or entirely on-premises deployment. Each option has different service coverage, different operational models, and different sovereignty guarantees. The underlying parent company remains a US legal entity, but the operational controls and contractual frameworks have been substantially strengthened.
The Azure model is well-suited for organizations that need flexibility across workload types and have existing Microsoft infrastructure and licensing that shapes the economics of any migration.
GCP: The controls-based model
Google Cloud’s approach to sovereignty is primarily policy and control-based rather than structural. Google offers Sovereign Controls for the EU, using a combination of Resource Hierarchy, Organization Policies, IAM Conditions, and VPC Service Controls to constrain where data flows and where Google operators can take action within your environment.
In practice, this means you can configure your Google Cloud environment to prevent data from leaving declared geographic contexts, restrict which Google operators can access your resources, and generate audit logs that demonstrate compliance to external parties. Google has also pursued sovereign cloud partnerships in Europe, working with local telecommunications and cloud providers to deliver compliance-focused services under local governance.
The GCP model is the most flexible in terms of service availability, because you are operating on standard GCP infrastructure with additional controls applied. It is the least separated in terms of corporate structure from US legal authority. The controls are technically sound, but they operate within the same legal entity that is subject to US jurisdiction.
This model is a good fit for organizations whose sovereignty requirements are primarily about data residency, access controls, and auditability, rather than structural independence from US legal authority. For regulated sectors with emerging requirements around operational sovereignty, it may not be sufficient.
The CLOUD Act question you need to answer
Every comparison of sovereign cloud providers eventually reaches the US CLOUD Act. This is the layer that technical data residency controls cannot fully address on their own.
The CLOUD Act (2018) allows US law enforcement to compel US-based cloud providers to disclose data stored anywhere in the world. The mechanism is a warrant or court order directed at the company, not at the infrastructure. A US company operating a datacenter in Germany can be required to produce data stored in that datacenter.
AWS ESC addresses this through structural separation: the operating entity is not Amazon Web Services, Inc. Microsoft addresses it through a combination of the EU Data Boundary’s legal commitments, contractual frameworks, and, for the most demanding requirements, the Sovereign Private Cloud where Microsoft itself has no access to the data. Google addresses it through access controls and audit trails, but within the same corporate structure.
The right answer depends on your regulatory context and your risk assessment. For most commercial organizations, the EU Data Boundary from either AWS or Microsoft provides adequate protection for most workloads. For organizations in critical infrastructure, healthcare, or financial services facing specific regulatory scrutiny, the structural question becomes more important.
What I would push back on is the idea that this question has a single right answer. It depends on what your regulators actually require, what your legal team has assessed, and what your risk tolerance is. Architects who treat this as purely a technical decision miss the legal layer entirely.
How to choose: the questions that matter
The sovereign cloud comparison is not a simple ranking from most sovereign to least. It is a mapping exercise. Your specific requirements, regulatory context, and existing infrastructure determine which architecture fits.
The first question is: what does sovereignty mean for your specific regulatory obligations? NIS2, DORA, GDPR, sector-specific national requirements, and, in some cases, explicit guidance from your national competent authority, all frame what is actually required versus what is marketing.
The second question is: what workloads are you moving, and do they all have the same sovereignty requirements? Most organizations have a mix. Some data is genuinely sensitive and may require the highest level of isolation. Other workloads can run on standard cloud infrastructure without sovereign constraints. Treating all workloads as requiring maximum sovereignty adds cost and reduces service availability unnecessarily.
The third question is: what is your existing infrastructure and tooling? Organizations with significant AWS investment and existing AWS skills face different migration economics than organizations starting from scratch or primarily on Azure or Google Cloud. Sovereign cloud is not a zero-cost migration project even when the architecture decision is clear.
The fourth question is: what does your multi-cloud strategy look like? It is entirely legitimate, and often the right answer, to use different providers for different workloads based on their specific sovereignty and operational requirements. The operational overhead of managing consistent security controls and identity across sovereign environments is real, but it is manageable with the right architecture.
What we look at when helping clients decide
At Cloud2, when we work on sovereign cloud architecture decisions, we start with the regulatory mapping before we touch the provider comparison. The provider comparison is an engineering exercise. The regulatory mapping is a business and legal exercise. Getting the order wrong wastes time.
Once we have a clear picture of what is actually required, the provider comparison becomes a question of which architecture satisfies those requirements with the most manageable operational overhead and the best fit to the organization’s existing capabilities.
A Cloud Review is typically where this starts. It gives us and the organization a concrete picture of the current cloud environment, what workloads exist, what their data classifications and compliance contexts are, and what the migration options look like. From that foundation, the sovereign cloud decision becomes specific rather than theoretical.
If your organization is working through a sovereign cloud decision and the conversation is still at the marketing materials stage, that is the right time to push into the architectural details. The differences between the three providers are real and consequential. Getting them right matters more than getting the decision made quickly.
