There is a simple but underappreciated policy direction hidden in the fevered debates over “sovereign clouds”: sovereignty is not achieved by hoarding bespoke stacks, it is achieved by making proven infrastructure commoditized and portable — in short, by turning the technologies that currently empower hyperscalers into interchangeable building blocks that governments, local providers, and new entrants can swap in and out without a costly, multi‑year re‑engineering project. The Tech Policy Press perspective argues precisely that governments should stop thinking about owning every layer of the stack and start thinking about how to make movement — of data, workloads, and developer expertise — as frictionless as possible.
Background / Overview
The policy problem is straightforward: a handful of U.S. hyperscalers — Amazon Web Services, Microsoft Azure, and Google Cloud — now control the digital substrate of modern economies. Their market dominance gives them pricing power, architectural de facto standards, and outsized influence on supply chains and geopolitics. Market reports and sector observers put the combined share of the top three providers at roughly two‑thirds of global IaaS/PaaS spend, a concentration that shapes choices for regulators and buyers alike. Two decades of cloud product design explain how we got here. Amazon introduced S3 in March 2006 as a universal, HTTP‑accessible object store; it established a de facto object storage API and semantics that many services and tools ultimately assumed. Microsoft first announced Windows Azure in October 2008 and only commercially launched Windows Azure (later Microsoft Azure) in 2010, developing a distinct storage model rather than adopting S3’s API. The result: divergent, incompatible platform primitives that made moving large systems between vendors costly and labor‑intensive. The policy question facing governments is thus not simply “who owns the cloud?” but “who can move workloads when the political, operational, or economic situation requires it?” The Tech Policy Press piece urges governments to make portability the metric of sovereignty: choose standards, procurement levers, and pragmatic interoperability over monolithic nation‑scale builds that replicate hyperscaler lock‑in under a different brand.
The original sin of cloud computing: lock‑in by design
How lock‑in happened
Two architectural decisions created the vendor lock‑in we face today.
- At the IaaS level, providers implemented regionally distributed compute, storage, and network primitives that looked similar on paper but diverged in APIs, operational assumptions, and failure modes.
- At the PaaS level, hyperscalers added high‑value convenience services — managed databases, serverless runtimes, identity providers, and AI tooling — each implemented with vendor‑specific APIs and operational semantics.
Those PaaS primitives dramatically lowered developer cost and time to market, making them irresistible to procurement teams and product owners, but they exacerbated switching costs. The outcome is a world where storage objects, serverless functions, or managed databases cannot be swapped without deep rewrites, data transformation, or retraining staff. The Tech Policy Press article calls this the cloud’s “original sin” — incompatibility as a business strategy.
The economic and human mechanics of lock‑in
Hyperscalers don’t just sell services; they train and certify developers, seed ecosystems of open‑source tooling aligned with their APIs, and underwrite partner programs that make integration with a single stack simpler than remaining vendor‑agnostic. The result is an economy of specialization — Google Cloud experts, AWS experts, Azure experts — and an employer market that reinforces vendor lock‑in as a career choice.
For public bodies, the calculus is blunt: build custom functionality at high cost, or use a managed platform feature today and accept higher exit costs later. Short budget cycles and political pressure favor the cheaper, faster option; that’s why procurement rules that limit PaaS use rarely survive program-level incentives. Practical procurement design must therefore be part of any strategy that wants to reduce lock‑in.
What governments did in the past: railways and gauges
History offers an instructive analog. In the nineteenth century, governments faced a similar fragmentation problem with rail gauges. Britain mandated a standard gauge in 1846 by statute (the Railway Regulation (Gauge) Act 1846), not because Stephenson’s gauge was objectively “best,” but because interoperability mattered more than perfect technical choices. In the United States, the Pacific Railroad Acts and subsequent political coordination set the stage for a unified gauge; the South’s broad‑gauge lines were converted in a coordinated operation around May–June 1886 in a matter of days. Those interventions show governments can impose or coordinate interoperability when the economic costs of fragmentation are existential. The policy lesson: standards and procurement can force network effects to work for public interest instead of rent extraction. But history also warns us: standardization works when governments pick the right axis (practical, broadly adopted interfaces) and when industry incentives align to adopt the standard.
A market‑shaping strategy for cloud sovereignty
The central recommendation is deceptively simple: treat sovereignty as an outcome of commodification — make the commodity (storage, identity, core microservices) truly interchangeable.
Two practical starting points crystallize this idea.
1) Bottom‑up: standardize storage around S3 compatibility
- Rationale: After nearly 20 years, S3 is the de facto standard for object storage. It is widely supported across clouds, CDNs, storage gateways, and open‑source projects.
- Policy lever: mandate that any provider receiving government procurement funds or delivering government‑funded cloud services must offer an S3‑compatible storage endpoint, certified by a national standards body.
- Effect: This would force incumbents and domestic challengers to either interoperate with S3 semantics or cede government business. It doesn’t require ripping out existing systems; it requires providers to expose a portable storage contract.
This approach acknowledges practical reality rather than inventing a novel protocol that lacks adoption. Several providers already offer S3‑compatible interfaces and third‑party gateways exist to mediate between Blob APIs and S3 semantics. Making S3 compatibility a procurement requirement would create a powerful market signal that reduces lock‑in risk while still allowing competition on price and service.
2) Top‑down: commodify platform microservices the government actually needs
- Rationale: Not all PaaS services are equally strategic. Governments should identify a small set of platform services (identity, payment, forms, notification, secure mail, legal eDiscovery) which, if open and portable, remove the most dangerous choke points.
- Policy lever: define open, minimal service contracts and require procurement for critical public workloads to use platform services conforming to those contracts. Invest in public implementations that can be operated on‑prem, by local providers, or by any compliant public cloud.
- Effect: Governments would get a baseline interoperability layer that agencies can depend on and swap between providers with minimal friction.
This is not a theoretical exercise — the UK’s Pay, Notify, and Forms services and India’s Digit/DigiLocker are practical examples of reusable government platform services that reduce duplication and lower integration cost. Where such platforms gain traction they can become de facto standards, reducing the need for regulation to coerce vendor behavior.
Lessons from procurement experiments: JEDI and the limits of regulation
The U.S. Department of Defense’s JEDI procurement (a proposed $10 billion cloud contract) is a revealing case study. JEDI attempted to use procurement to create a de facto government standard by requiring interoperability and allowing joint bids. The effort faltered under legal challenges, shifting political priorities, and changing technical requirements; the DoD ultimately canceled JEDI and moved to a multi‑vendor Joint Warfighter Cloud Capability. The lesson: procurement can be a market‑shaper, but it requires durable political alignment and careful technical design to avoid providing incentives for litigation rather than interoperability. Europe’s Gaia‑X and regulatory efforts show the opposite risk: building new de jure standards or governance frameworks that lack market traction is unlikely to beat de facto standards already embedded in developer tooling and production systems. The pragmatic path, then, is to align procurement power with existing technical realities and nudge vendors to interoperate — not to force them to adopt hypothetical new protocols.
Recent wakes — outages and physical failures that reframed risk
Operational incidents since 2024 have sharpened the policy conversation.
- October 20, 2025: a major AWS US‑EAST‑1 outage caused widespread disruption across entertainment, productivity, and consumer services; root‑cause reporting points to DNS and automation failures that cascaded through DynamoDB and other services.
- October 29, 2025: a large Microsoft Azure outage linked to an inadvertent configuration change in Azure Front Door caused disruptions to airlines, government portals, and gaming services.
- September 26, 2025: a catastrophic fire at South Korea’s National Information Resources Service (NIRS) data centre in Daejeon destroyed the G‑Drive system and may have permanently erased up to 858 TB of government data because backups were co‑located and thus also lost; this incident is a stark reminder that “sovereign” physical control is not the same as resilience.
These events show three things at once: hyperscaler outages can cascade globally; configuration complexity creates systemic failure modes; and sovereign or local infrastructures can fail catastrophically if designed without geographically isolated backups and tested redundancy. Markets and procurement must reward demonstrable resilience, not mere rhetoric about local ownership.
A pragmatic policy checklist for governments
- Classify and tier workloads.
- Reserve “sovereign” guarantees for the small subset (10–20%) of services that would cause material national harm if disrupted.
- Mandate S3‑compatibility for government‑funded or certified storage services.
- Certification can be incremental and time‑bounded to give industry a practical adoption path.
- Define minimal open contracts for core government PaaS (identity, forms, notifications).
- Build and fund public implementations that can act as reference or anchor tenants.
- Use procurement as a market‑shaper.
- Insist on data portability clauses, tested exit playbooks, and disaster recovery drills as part of procurement awards.
- Invest in operational capacity.
- Sovereignty without SRE, training, and budget for ops is symbolic. Fund the operational staffing, audits, and exercises needed to make failovers credible.
- Coordinate internationally where possible.
- Storage standards and basic platform contracts are natural cross‑border public goods; alignment magnifies leverage.
These measures emphasize agency over ownership: the goal is to make it easy to move workloads, not to own every server.
Strengths of the commodification approach
- Practicality: recognizing existing de facto standards (S3) is far simpler than inventing new global protocols and trying to make them stick.
- Leverage: procurement is a powerful lever — governments buy enough cloud that even modest technical requirements can reshape vendor behavior.
- Cost‑effectiveness: interoperable services enable competition and drive providers to compete on service, price, and operational quality rather than on lock‑in.
- Inclusiveness: commodification is a path accessible to mid‑size countries and smaller economies because it lowers the capital barrier to entry for local providers who can offer value through specialization and governance guarantees.
Risks, tradeoffs and unanswered questions
- Political will and bureaucracy: standardization takes decades when politics shifts in short cycles. JEDI’s cancellation is a cautionary tale about alignment.
- Vendor resistance: some incumbents may litigate, lobby, or slow‑roll technical compatibility to protect margins. Expect tight legal fights and aggressive commercial behavior.
- Standards governance: turning de facto interfaces into stable, governed standards requires institutions to manage evolution, security, and backward compatibility — something governments have limited track records with in software.
- Operational burden: building domestic operational capacity is expensive. Sovereignty without staff is an empty promise, and open‑source stacks still require professional SRE teams.
- Misplaced nationalism: insisting only on domestic ownership can produce worse lock‑in — domestic monopolies or underfunded “sovereign” stacks that are expensive, insecure, and brittle.
Flagged uncertainties: Some numbers circulating in public discussions (for example, cumulative national spend figures or characterizations of specific contractual guarantees) vary across reporting outlets and require procurement‑level verification. Treat headline figures as signposts to investigate, not as procurement‑grade facts.
How this reframes “sovereignty”
Commodification redefines sovereignty from “I own my stack” to “I control my options.” That subtle semantic shift matters. Ownership is expensive, exclusionary, and brittle; portability and interoperability are inclusive and dynamic. If governments can move workloads across suppliers cheaply and predictably, they have practical agency without having to finance a continent‑scale cloud.
This is not anti‑industry. The strategy wants hyperscaler participation: cheaper, faster, and more resilient services are wins for everyone. The aim is to change incentives so that providers compete on price, performance, and governance guarantees instead of extracting rents through opaque platform lock‑in. Procurement, along with regulatory teeth where necessary, creates the right mix of carrots and sticks.
Practical next steps for IT leaders and procurement teams
- Inventory dependencies: map vendor‑specific primitives (managed DBs, identity, AFD/CLOUDFRONT equivalents).
- Pilot S3 portability: run a migration test for non‑critical workloads to measure actual migration cost and time.
- Demand exit plans: insist on contractually binding exit playbooks and third‑party verification of portability.
- Test DR rigorously: conduct cross‑provider failover exercises and check that backups are geographically isolated (learn the hard lesson from South Korea’s NIRS fire).
- Prioritise human capacity: fund SRE, procurement, and legal teams with cloud portability expertise.
Conclusion — a ten‑year bet governments can win
The political and technical work required is hard and long — standardizing markets is rarely glamorous — but it is tractable. Governments have successfully shaped the physical infrastructure of prior centuries: rail gauges, electricity grids, and telecommunications. The cloud layer is the next public utility to be disciplined by rules that favor portability and competition.
The right objective is clear: not to destroy the hyperscalers, but to
tame them — to create a market where vendors earn customers by offering better service and genuine portability rather than by erecting proprietary moats. If governments can coordinate procurement demands around pragmatic, widely‑adopted interfaces (starting with S3‑compatible storage and a small set of open platform services), they can make meaningful sovereignty achievable for many countries, not just the richest few. The alternative — expensive, fragmented sovereign stacks that recreate the same lock‑in problems under different flags — is predictable and avoidable.
Bold, realistic choices — exercised patiently through procurement, standards, and operational investment — can make sovereignty an outcome of market architecture rather than a monument to political bravado.
Source: Tech Policy Press
The Path to a Sovereign Tech Stack is Via a Commodified Tech Stack | TechPolicy.Press