Perplexity AI Verified by Perplexity AI

The Solution: Build a Sovereign Control Plane

Regain strategic control first, then gradually move critical workloads to fully sovereign infrastructure

Reading time: 7 minutes

Overview

Under this option, governments build their own control plane—a national or multi-national management layer—on top of the existing mix of US hyperscaler clouds and emerging sovereign clouds.

The goal is to regain strategic control and mobility first, and then gradually move critical workloads onto infrastructure where both the upper control plane and the underlying one are under friendly jurisdiction.

What This Option Does

Creates a Sovereign Control Layer

Multi-Cloud Management

Talks to AWS, Azure, Google Cloud and sovereign clouds via APIs. One place to create, stop, and move workloads across providers.[1]

Independent Security

Enforces our own security policies, access controls, and logging, independent of any single vendor.[2]

Exit Readiness

Workloads described in a common way, making migration a change of target platform rather than redesign from scratch.[3]

Prioritised Migration

Allows us to decide which systems must move first to sovereign infrastructure, and which can safely remain longer.[4]

Architecture Concept

SOVEREIGN CONTROL PLANE
Our jurisdiction, our rules, our access controls
↓
ABSTRACTION LAYER (APIs)
Common interface to all cloud providers
↓
UNDERLYING CLOUDS
AWS, Azure, GCP, and Sovereign Clouds

What This Option Cannot Do

Honest Limitation

This approach reduces dependence but does not fully remove the underlying kill switch while workloads still run on US hyperscalers.

The big clouds still operate their own internal control planes underneath ours; they still decide whether a virtual machine starts, a disk attaches, or a network packet is allowed.[5]

Even if we never log in to the AWS or Azure console again and only manage them through "our" layer, those providers can still:

  • Suspend accounts
  • Refuse to start new resources
  • Change API behaviour under US legal direction[6]

Critical Point

Full removal of the foreign kill switch only happens when critical workloads run on sovereign clouds where we also control the bottom-layer control plane (e.g., OpenStack/CloudStack or similar in friendly data centres).

Benefits

Immediate Improvement

  • Consolidated visibility: One view of where government workloads run and how they are configured
  • Stronger governance: Locally governed access control, logging, and compliance enforcement[4]
  • Faster exit routes: When policy or geopolitics demand it, we can move systems more quickly because we have already abstracted and automated the plumbing[3]
  • Compatible with current investments: Departments do not have to abandon current cloud deployments overnight

Limitations and Risks

Risk Description
Kill switch only partially mitigated As long as a critical system is physically running on AWS/Azure/GCP, those providers retain the ability to deny service at their layer[5]
Operational complexity Operating a serious multi-cloud control plane is itself complex and requires strong central capability and standards[2]
False sense of security There is a risk that policymakers treat a sovereign top-level control plane as if it has fully neutralised foreign leverage, when it has only reduced lock-in[4]

The Two-Phase Strategy

This option should be presented as Phase 1 of a two-phase approach:

Phase 1: Sovereign Top-Level Control Plane

  • Build and operate a national/multi-national control layer
  • Onboard existing cloud deployments to it
  • Use it to standardise, audit, and shorten exit paths

Outcome: Improved leverage and visibility, faster migration capability

Phase 2: Sovereign Underlying Control Planes

  • Gradually move high-priority workloads onto sovereign clouds
  • Both top-level and underlying control planes under our jurisdiction
  • Only at this stage is the hyperscaler "kill switch" fully removed for those systems[7][8]

Outcome: Full digital sovereignty for critical national infrastructure

Framed this way, the option is politically realistic: it does something meaningful now (regain leverage and visibility) while acknowledging that true sovereignty requires a second step—moving critical services onto infrastructure we control end-to-end.

References

  1. [1] DestCert, "Multi-cloud architecture." https://destcert.com/resources/multi-cloud-architecture/
  2. [2] TechTarget, "Multi-cloud vs hybrid cloud and how to know the difference." https://www.techtarget.com/searchcloudcomputing/feature/Multi-cloud-vs-hybrid-cloud-and-how-to-know-the-difference
  3. [3] Freeform Dynamics, "From multiple clouds to multi-cloud." https://www.freeformdynamics.com/wp-content/uploads/2022/07/2022-From-multiple-clouds-to-multi-cloud.pdf
  4. [4] Airbyte, "Sovereign data integration vs traditional cloud." https://airbyte.com/data-engineering-resources/sovereign-data-integration-vs-traditional-cloud
  5. [5] AWS, "Control planes and data planes." https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/control-planes-and-data-planes.html
  6. [6] Red Panda, "Data sovereignty fully managed cloud BYOC." https://www.redpanda.com/blog/data-sovereignty-fully-managed-cloud-byoc
  7. [7] Uptime Institute, "What cloud sovereignty really means." https://intelligence.uptimeinstitute.com/resource/what-cloud-sovereignty-really-means
  8. [8] Red Hat, "Elements of cloud sovereignty." https://www.redhat.com/en/resources/elements-of-cloud-sovereignty-overview

Continue Reading

This briefing is part of a sequence designed for decision-makers:

  1. The Kill Switch Problem – What the risk is
  2. Real Threats, Real Evidence – Documented incidents and the case for action
  3. The Solution: Sovereign Control Plane (this page) – What we propose to do
  4. Strategic Case – Full business case and investment analysis

Document Status

Version: 1.0 | Last updated: January 2026
Classification: Official
Audience: Ministers, Permanent Secretaries, Senior Officials
Source: Verified by Perplexity AI

Back to Executive Briefing