Sovereign Cloud Systems
Design sovereign cloud systems by separating residency from authority, controlling identity and keys, proving operations, testing recovery, and planning exit.
What is a sovereign cloud system?
A sovereign cloud system is a cloud architecture that keeps a defined workload inside enforceable legal, data, and operational control boundaries. It specifies where every data copy can exist, which identities may administer the service, who can authorize key use, which operators can recover it, and which outside dependencies may remain.
In plain language, a local cloud region answers where some equipment is located. A sovereignty design answers which authority can make a sensitive system disclose data, change policy, restore service, or stop operating.
The core invariant is: no actor or dependency may cross the workload's declared control boundary without an authorized, recorded, and reviewable decision. Residency is one control inside that boundary, not proof of sovereignty by itself.
Legal counsel and risk owners translate applicable law, contracts, classification rules, and government policy into a workload-specific control contract. Architecture then enforces and produces evidence for that contract; it does not guess what the law requires.
Draw four boundaries before choosing a provider
A boundary states what is inside the allowed system and what must be treated as an external dependency. Four related boundaries prevent the phrase “sovereign cloud” from hiding different requirements.
Which authority applies?
Legal boundary
Name the entities, jurisdictions, contracts, lawful-access paths, and sector rules that govern the workload. Physical location does not remove every legal obligation or provider exposure.
Where may bytes exist?
Residency boundary
List every regulated surface: primary data, replicas, backups, indexes, logs, support bundles, telemetry, and derived datasets. “Stored locally” is incomplete when another copy crosses the boundary.
Who may decide?
Authority boundary
Assign identity, key, privileged-operation, policy, and recovery authority. Check whether the provider can act unilaterally or whether customer-held approval can deny access.
What must remain reachable?
Dependency boundary
Trace control planes, identity services, key services, update channels, licensing, support access, and restore tooling. A local workload can still stop when a foreign dependency disappears.
Data residency means specified data remains in an approved location. Data sovereignty is broader: the workload is governed and operated under the required legal and control authorities. A system can meet residency while failing sovereignty when its root identity, key release, administrator path, or recovery control remains outside the boundary.
Assign authority to concrete control planes
An authority plane is the mechanism through which an actor can approve, deny, or execute a sensitive action. Product names matter less than who holds the root of trust and who can override whom.
A request crosses several independent authorities
A single local administrator account is not enough. Each plane needs an owner, an enforcement point, an emergency path, and evidence.
1. Authenticate
Identity authority
A customer-controlled identity root issues administrator identities, applies strong authentication, and can revoke access without depending only on provider accounts.
2. Authorize use
Key authority
The key service decides whether ciphertext can become usable data. The design must state who can release, rotate, disable, escrow, and recover keys.
3. Change
Operations authority
Privileged changes pass through approved operators, dual control where required, bounded support access, and locally retained audit records.
4. Restore
Recovery authority
Break-glass credentials, runbooks, backups, and clean recovery capacity remain usable when the normal provider control plane is unavailable or untrusted.
For each plane, document:
- Decision owner: the accountable organization and role that may approve the action.
- Technical enforcer: the identity provider, policy engine, HSM, deployment controller, or recovery service that can block it.
- Provider capability: whether provider personnel or automation can bypass, reset, impersonate, or recover the control.
- Emergency rule: who may invoke break glass, for how long, with which second approver, and what must be rotated afterward.
Decide whether a workload may be placed
Workload placement maps one classified workload to a platform and authority model whose controls satisfy its contract. Place the lowest-risk public workload differently from resident records or restricted case files; “one sovereign landing zone” is rarely a complete decision.
Choose a workload, platform, and authority model below. Watch local data surfaces and decision authority change independently. A result is acceptable only when every mandatory boundary passes.
Evaluate location and control separately
Loading workload, platform, and authority contracts.
Use deny-by-default placement. If classification, jurisdiction, key authority, operator eligibility, or evidence requirements are unknown, quarantine the deployment request instead of selecting the nearest region.
Turn the boundary into an executable placement contract
A placement contract is a versioned policy record that connects business classification to infrastructure controls. It should be evaluated before provisioning and continuously after deployment because backups, logs, support sessions, and service dependencies can drift.
1 Scope
Classify the workload
Record data categories, subjects, purpose, legal owner, allowed jurisdictions, retention, availability target, and exit deadline. Unknown classification stops placement.
2 Locate
Resolve every data surface
Map primary stores, replicas, backups, caches, indexes, queues, logs, telemetry, support artifacts, and disaster-recovery copies to approved locations.
3 Authorize
Bind control authority
Attach approved identity roots, key policies, operator groups, support-access rules, deployment signers, and break-glass custodians to the workload.
4 Enforce
Admit and re-evaluate
Reject nonconforming resources before creation, then monitor configuration, access, key use, data movement, dependencies, and evidence freshness for drift.
The contract should use immutable workload and policy identifiers. Evidence must show which policy version allowed a placement, not only the platform's current configuration.
Evidence must prove the control actually operated
Sovereignty evidence is the durable record that connects a requirement, an enforcement decision, and an observed result. Certifications and provider attestations help establish inherited controls, but the workload owner still needs evidence for its own identities, keys, placements, operations, and recovery tests.
What exists?
Configuration evidence
Keep signed policy versions, resource inventories, region and zone assignments, backup destinations, network routes, key bindings, dependency manifests, and deployment provenance.
What happened?
Activity evidence
Retain administrator authentication, authorization decisions, key-use events, privileged commands, support sessions, exports, policy denials, and cross-boundary transfer approvals.
Can it be restored?
Recovery evidence
Record restore drills, break-glass approvals, credential use, recovery time, data-loss measurement, integrity checks, key rotation, and remediation owners.
Evidence has its own sovereignty requirements:
- Store a tamper-evident copy under an authority that the observed administrator cannot rewrite.
- Keep clocks, actor identities, workload IDs, policy versions, locations, and decision reasons consistent enough to reconstruct an event.
- Test evidence retrieval during provider isolation; an audit trail reachable only through the failed control plane cannot support recovery or investigation.
- Define retention and access rules for logs because logs and support bundles may contain regulated data.
Recover without silently surrendering the boundary
Break-glass recovery is a pre-authorized emergency path used when normal controls are unavailable. It is not an undocumented superuser. A credible path uses separate credentials, multiple custodians, time-bounded access, a clean recovery environment, immutable evidence, and mandatory post-use rotation.
Select a dependency failure, recovery design, and exit package. The lab distinguishes high availability, sovereign recovery, and provider exit by showing which missing dependency blocks each choice.
Test recovery against the failed dependency
Loading dependency failures, break-glass plans, and exit packages.
Separate availability, recovery, and exit
These three capabilities protect different failure boundaries. Buying one does not automatically provide the others.
Keep serving
High availability
Replicas and failover inside the same provider can survive machine or zone failure. They may still share identity, key, control-plane, legal, and billing dependencies.
Restore independently
Sovereign recovery
Customer-authorized break glass, accessible keys, isolated backups, clean capacity, and an offline runbook restore service when normal provider administration is unavailable.
Leave deliberately
Exit portability
Open data formats, schemas, infrastructure definitions, identity mappings, key-transition procedures, dependency replacements, and a tested target bound vendor exit time.
Define an exit trigger before procurement. Useful triggers include loss of certification, unacceptable legal exposure, prolonged control-plane isolation, product retirement, unbounded price change, or provider insolvency. For each trigger, name:
- the maximum time to move or restore the workload;
- the acceptable data-loss window and last independently readable backup;
- the services that need portable substitutes, not merely exported data;
- the owner and budget for repeated restore and migration rehearsals.
Apply the model to production workloads
A production pattern combines only the controls justified by one workload's contract. Avoid both under-control and expensive uniform isolation.
Regulated records
Resident benefits service
Keep records, indexes, logs, and backups in approved locations. Use customer-rooted administrator identity, customer-authorized keys, screened operations, and evidence that links every export to a legal purpose and policy version.
Controlled collaboration
Health research workspace
Keep identifiable source data in the approved zone. Release de-identified or aggregated outputs through a policy gateway, record transformations, and prevent notebooks or telemetry from becoming hidden export paths.
Operational continuity
Critical industrial control
Keep safe local operation independent of the WAN. Replicate bounded evidence to the sovereign platform, retain local recovery authority, and test behavior when remote identity, update, and support services disappear.
Implement policy and recovery as testable code
The first example evaluates an immutable placement request against location, authority, dependency, and evidence requirements. It returns explicit denials rather than a vague score.
The second example validates a break-glass plan before a drill. It rejects a plan that depends on failed provider services, lacks dual control, exceeds the recovery target, or cannot produce the required evidence.
Review the design as a chain of proof
A sovereignty readiness review checks whether the declared boundary remains enforceable during normal operation, emergency recovery, and provider exit.
- Legal and workload scope
- Every workload has an accountable owner, classification, purpose, allowed locations, authority rules, retention, recovery target, and exit trigger.
- Legal assumptions have review dates and are translated into testable controls without claiming architecture alone guarantees compliance.
- Data and authority
- Primary data, replicas, backups, indexes, queues, logs, telemetry, and support artifacts are included in placement policy.
- Identity, key, operations, policy, support, and recovery authority are assigned; unilateral provider capability is documented and accepted or prevented.
- Operations and evidence
- Privileged access is just-in-time, scoped, approved, recorded, and independently reviewable.
- Policy decisions, key use, data movement, restore drills, and denials remain retrievable during control-plane isolation.
- Recovery and exit
- Break glass uses separate credentials, dual control, a clean environment, time limits, integrity checks, and post-use rotation.
- Portable data, schemas, infrastructure, identity mappings, key transition, replacement dependencies, and a tested target meet the exit deadline.
The design is not complete when every box says “local.” It is complete when owners can explain who has authority, demonstrate the controls, recover without the failed dependency, and leave within an accepted time.