The Conversation That Changed Character
Three years ago, the sovereign cloud conversation in European enterprises was primarily a compliance conversation. Does our cloud architecture meet GDPR data residency requirements? Are we subject to CLOUD Act exposure? What data sovereignty protections does our hyperscaler’s EU offering provide?
These compliance questions had manageable answers. The major hyperscalers had built EU data boundary offerings, data residency commitments, and sovereignty frameworks designed to address the regulatory requirements as they were understood. For most organisations, the compliance answer was: use EU regions, enable the appropriate sovereignty controls, document the residency configuration.
The conversation has changed character. Compliance remains a component, but the strategic question has broadened: what is the appropriate level of dependency on US-headquartered hyperscalers for the infrastructure that underlies European enterprise operations? This question is being driven by three forces that are more durable and more complex than the compliance questions they sit alongside.
The Three Forces Driving the Rethink
Geopolitical supply chain risk became tangible for European enterprises in a way it had not been previously. The dependency of critical industrial, logistics, and government operations on US hyperscale cloud infrastructure became visible in the discussions about potential technology decoupling scenarios that have appeared in geopolitical risk assessments since 2022. Boards and governments that had treated hyperscaler cloud as an infrastructure utility with stable supply chain characteristics began to ask what the continuity plan was if that supply chain became constrained.
The honest answer, in most cases, was that there was no credible continuity plan at the infrastructure level. The cloud-native applications built to run on AWS or Azure cannot be ported to an alternative infrastructure in a timeframe that would be relevant in a supply chain disruption scenario. The dependency was structural, not just contractual, and the structural dependency had not been assessed as a strategic risk.
Regulatory tightening beyond current hyperscaler capabilities is the second force. The EU AI Act’s requirements for high-risk AI system transparency, audit rights, and data governance go beyond what the hyperscaler sovereignty frameworks currently provide in practice. The emerging requirements around algorithmic transparency for financial services AI under DORA create similar gaps. The NIS2 supply chain security provisions, properly interpreted, raise questions about the visibility that covered entities have into their hyperscaler’s security operations. The regulatory direction is toward more stringent requirements on how sensitive European data is processed and controlled, and the hyperscaler offering is not evolving at the pace required to stay ahead of those requirements.
European cloud alternatives have reached a credibility threshold they had not previously achieved. Three to five years ago, the honest assessment of European hyperscaler alternatives was that they were credible for specific workloads but not for the general-purpose cloud capability that enterprise workloads require. That assessment is less accurate now. OVHcloud, Hetzner, Deutsche Telekom’s Open Telekom Cloud, and a range of national and sector-specific cloud providers have matured significantly. The assessment should be revisited against 2025 capability rather than 2021 capability.
The Architectural Options That the Rethink Enables
The sovereign cloud architectural decision for European enterprises is not a binary choice between full hyperscaler dependency and full European cloud adoption. It is a portfolio decision about which workloads to run where, based on a combination of regulatory requirements, geopolitical risk assessment, performance requirements, and cost.
The Tier 1 workload category consists of systems that process data subject to the most stringent sovereignty requirements: personal data of EU citizens processed for regulated purposes, classified government information, critical infrastructure operational data. For these workloads, the strongest sovereignty case points toward on-premises infrastructure, European cloud providers with genuine sovereignty architecture (not just EU data residency from a US-headquartered provider), or hybrid architectures that keep sensitive data and processing within a sovereign perimeter while using hyperscaler services for less sensitive workloads.
The Tier 2 workload category consists of systems that process sensitive business data where sovereignty is a preference rather than a hard requirement, and where the performance and capability requirements are well served by the hyperscaler offering. For these workloads, the hyperscaler with appropriate EU data boundary controls and contractual protections is a reasonable choice, with the risk managed through contractual terms, vendor dependency monitoring, and a migration plan that is documented and periodically tested rather than just assumed.
The Tier 3 workload category consists of development environments, test systems, and workloads that process non-sensitive data where the hyperscaler’s cost efficiency and global capability are clear advantages and sovereignty risk is low.
The organisation that has explicitly classified its workloads across these tiers has a sovereign cloud architecture strategy. The one that has deployed everything on a single hyperscaler without this classification has made an implicit strategic choice that may not survive the next strategic review.
The Migration Planning Reality
The sovereign cloud conversation often stalls at the recognition that migration from hyperscaler infrastructure is complex and costly. This recognition is accurate but is not a reason to avoid the strategic conversation. It is a reason to begin the migration planning.
Migration from hyperscaler infrastructure is complex because modern cloud-native applications use hyperscaler-specific services that do not have direct equivalents in alternative environments. The managed database, the serverless compute service, the AI inference endpoint: each is a hyperscaler-specific service dependency that creates migration friction. The migration plan that addresses these dependencies honestly will be a multi-year plan for complex applications, and it should be assessed as such.
The strategic question is not “can we migrate?” but “should we migrate, which workloads, and over what timeframe?” The workload tier classification described above is the starting point. The Tier 1 workloads that should be on sovereign infrastructure may already be there if the organisation has been thoughtful about data classification. The Tier 1 workloads that are on hyperscaler infrastructure have the strongest migration case and the clearest migration motivation.
The Board Decision This Requires
The sovereign cloud strategy is a board-level strategic decision, not a technology architecture decision that the CTO can make unilaterally. It requires board input because it involves strategic risk assessment (how much supply chain concentration risk is acceptable), regulatory risk assessment (what does the regulatory trajectory mean for our current architecture), and financial trade-offs (what is the cost of the sovereignty architecture compared to the risk it mitigates).
The board that has not had this conversation has implicitly accepted the status quo as the strategic choice. Given the three forces described above, that implicit acceptance deserves to be made explicit and subjected to the same scrutiny as any other strategic risk decision.
The cloud architecture decisions made in the next twelve to twenty-four months will determine the organisation’s flexibility and risk profile for the decade that follows. The sovereign cloud question belongs in that decision.