Cloud / Infrastructure Providers — Sovereignty Matrix¶
Companion to tools.md. The tool tracker classifies application network topology (Zones 1–4). This table classifies the substrate you deploy on — a different axis. A Zone 3 (federated) app running on a hyperscaler VM is still architecturally Zone 3, but the provider becomes a privileged operator in your trust model. That hybrid is exactly what the Operator and Zone (Ops) columns in the tool tracker exist to capture.
Validation status. Overall Sovereignty risk ratings are
[HYPOTHESIS]— Kevin's reasoned assessment, not measured or counsel-reviewed. Jurisdiction / legal-compulsion claims (CLOUD Act reach, GDPR posture) are documented statutory reality but[EXPERT REVIEWED]-pending — they need an attorney before they're load-bearing in any external or compliance context. Data-mining posture reflects each provider's published terms as of 2026-06; "won't" is a contractual promise, not an architectural guarantee.
The key distinction¶
Cloud hosting is substrate, not topology. "What zone is AWS?" is partly a category error:
- As a product they sell you (Gmail, Workspace, iCloud, M365, managed PaaS) → Zone 4 walled garden; the data relationship is the product.
- As raw IaaS (a VM / VPS / object store) → zone-neutral substrate; your app sets the zone. You can run a Zone 1, 3, or 4 application on it.
So a hyperscaler can't be "made Zone 3." What you can do is deploy a Zone 3 app on its IaaS — leaving you with a Zone 3 application on a Zone 4 substrate. The sovereignty question is: what does the substrate operator see and control?
Matrix¶
| Provider | Service tier | Jurisdiction | Privileged access | Data-mining posture (IaaS) | Customer-held keys? | Sovereignty risk | Notes |
|---|---|---|---|---|---|---|---|
| AWS | IaaS + PaaS + SaaS | US (CLOUD Act) | Host/hypervisor; owns hardware | Terms: not used except to provide service | Yes — KMS, CloudHSM, External Key Store (XKS) keeps keys off-provider | High (mitigable) | The default hyperscaler. No consumer-ad business behind the IaaS, but US legal reach + privileged host access remain. |
| Google Cloud (GCP) | IaaS + PaaS + SaaS | US (CLOUD Act) | Host/hypervisor; owns hardware | GCP workloads contractually separate from Google's ad business; not mined | Yes — Cloud KMS + External Key Manager (EKM) | High (mitigable) | Reputational nuance: Google's consumer core is data-driven; GCP IaaS is contractually walled off — but that's policy separation, not architectural. |
| Microsoft Azure | IaaS + PaaS + SaaS | US (CLOUD Act) | Host/hypervisor; owns hardware | Terms: not used except to provide service | Yes — Key Vault, Managed HSM, hold-your-own-key | High (mitigable; best sovereign-cloud roadmap) | Microsoft Cloud for Sovereignty + EU Data Boundary are the furthest-developed hyperscaler sovereign offerings — narrows (not removes) US jurisdiction exposure. |
| Apple / iCloud | SaaS only | US (CLOUD Act) | N/A as substrate | N/A — no general IaaS | Partial — Advanced Data Protection = E2E for most iCloud categories | N/A as substrate | Not a VPS/IaaS provider — no EC2 equivalent. Devices + consumer cloud. iCloud = Zone 4 SaaS. Belongs here only to correct the "Apple = hyperscaler substrate" framing. |
| Oracle Cloud (OCI) | IaaS + PaaS | US (CLOUD Act) | Host/hypervisor; owns hardware | Terms: not used except to provide service | Yes — OCI Vault / external HSM | High | Less common for our profile; included for completeness. |
| DigitalOcean / Linode | IaaS / VPS | US (CLOUD Act) | Host/hypervisor; owns hardware | No consumer-data business; not mined | Partial — bring-your-own disk encryption; weaker managed-KMS story | Medium–High | Simpler, developer-scale VPS. Same US jurisdiction; smaller blast radius and no ad business. |
| Hetzner | IaaS / VPS / bare metal | EU (DE/FI) — GDPR, no direct CLOUD Act nexus | Host/hypervisor (VM) or none (bare metal) | EU company, no ad business; not mined | Partial — you manage encryption | Medium | EU jurisdiction materially lowers US-compulsion exposure for EU-resident data. Cheap; bare-metal option removes the hypervisor layer. |
| OVHcloud | IaaS / VPS / bare metal | EU (FR) — GDPR; SecNumCloud-track offerings | Host/hypervisor or none (bare metal) | EU company, no ad business; not mined | Partial — you manage encryption | Medium | French sovereign-cloud lineage; bare metal available. |
| Colocation / bare metal | Space + power + network only | Yours (choose the facility) | Physical only — no hypervisor; you own the box | None — provider never touches the OS | Yes — you hold everything | Low–Medium | You own the hardware; provider sells rack space. Removes host-software access entirely. Trade-off: capex + ops burden. |
| Self-host / Second Boot refurb server | Your own hardware | Yours | None external — Operator: self |
None | Yes | Low | Lowest sovereignty risk; Operator: none/self. Trade-offs: uptime, bandwidth, physical security, ops load. Ties to GoToSocial's "single-binary on Pi-class" note and the Reuse-over-new-manufacture sustainability directive. |
Mitigation ladder (weakest → strongest sovereignty)¶
- Trust the terms — rely on the provider's contractual "we don't mine your workload." Policy-based; the DuckDuckGo tier. They can, they say they won't.
- Encrypt at rest with customer-managed keys held off-provider (AWS XKS / GCP EKM / Azure HYOK). The host can't read disk without your key. Still sees RAM + metadata.
- E2E in the application so the server only ever holds ciphertext — the Proton model on your own infra. Converts host-access and data-mining from "trust the policy" to "architecturally can't read it." Strongest single lever.
- Confidential computing (encrypted memory / TEEs) — closes the host-reads-RAM gap left by (3).
[HYPOTHESIS]for BNI's needs; newer, not yet evaluated. - EU / sovereign substrate (Hetzner, OVH, Azure Sovereignty) — narrows legal-jurisdiction exposure, orthogonal to crypto.
- Bare metal / colo / self-host — removes the hypervisor and the third-party operator entirely. Highest sovereignty, highest ops cost. The Second Boot refurb-server path lives here.
Metadata never fully disappears short of (6): even with perfect E2E, a hyperscaler sees IPs, traffic volume, and peering. Same content-vs-metadata split that keeps Proton in Zone 4.
Bottom line for a Zone 3 / federated BNI deployment¶
- Deploying on hyperscaler IaaS does not change the app's zone — it stays Zone 3.
- It does insert the provider as a privileged operator: host access, US legal compulsion, and metadata visibility are real; active data-mining of the workload is contractually disclaimed but not architecturally prevented.
- The risk is bounded and largely mitigable by stack (3) — customer-held keys + E2E so the server holds only ciphertext.
- For the lowest-sovereignty-risk profile that also serves the reuse / off-grid sustainability mission, self-hosted refurb hardware (Second Boot) or EU bare metal is the strongest fit — at the cost of operational burden.
Known Unknowns¶
- Counsel review pending on CLOUD Act reach for an EU-hosted-but-US-incorporated entity (BNI is US — does using Hetzner actually shield BNI-controlled data, or does BNI's own US nexus re-expose it?).
[EXPERT REVIEWED]needed before relying on EU hosting for jurisdictional protection. - Confidential-computing maturity on the candidate substrates — unevaluated.
- Bandwidth / uptime economics of self-hosting a federated instance at pilot scale — not yet costed against a $5–20/mo VPS.
- Whether any BNI Zone 3 service is actually planned for cloud deployment yet, or whether this matrix is pre-decision scaffolding. (Currently: pre-decision —
[HYPOTHESIS].)
Related: tools.md (application-topology tracker) · GoToSocial row (Pi-class self-host reference) · Sustainability & Carbon Awareness directive (reuse / off-grid).