Un sovereign cloud è un’infrastruttura in cui mantieni il controllo legale, operativo e tecnico sui tuoi dati e sistemi, invece di affittare quel controllo da qualcun altro. I dati risiedono dove decidi tu, le chiavi di crittografia le detieni tu e nessuna giurisdizione straniera può accedere silenziosamente ai tuoi sistemi. Per le organizzazioni europee, e tedesche in particolare, questo è passato da un optional a un requisito a livello di consiglio di amministrazione, spinto da GDPR, NIS2, DORA e dalla portata del CLOUD Act statunitense.
La buona notizia: non esiste un unico prodotto sovereign cloud “corretto” da acquistare. Un sovereign private cloud può essere costruito in molti modi, quasi interamente su open source e standard aperti. Questa guida spiega cosa significhi davvero il termine, poi illustra il panorama reale dei modi per costruirne uno, così da abbinare l’approccio ai tuoi carichi di lavoro anziché al marketing di un vendor.
Cosa significa davvero “sovereign”
La residenza dei dati (dove i byte si trovano fisicamente) è solo un tassello. La vera sovranità digitale combina più elementi tra loro:
- Controllo giurisdizionale - i tuoi dati restano fuori dalla portata di leggi straniere, in linea con i regimi UE come GDPR, NIS2, DORA e l’EU Data Act.
- Controllo delle chiavi - le chiavi di crittografia le detieni tu (BYOK, o pienamente HYOK), non l’operatore della piattaforma.
- Controllo operativo - decidi tu chi può accedere, modificare e verificare l’ambiente.
- Portabilità - interfacce aperte e standard (Kubernetes API, OCI, S3) ti permettono di andartene o spostarti senza riscrivere nulla.
- Trasparenza - componenti open source che puoi ispezionare, più confidential computing opzionale (Intel TDX, AMD SEV-SNP) per la protezione a runtime.
Framework utili da conoscere mentre definisci un progetto: Gaia-X e le sue label del Trust Framework, l’imminente schema di certificazione EUCS di ENISA, il catalogo BSI C5 tedesco e il Sovereign Cloud Stack (SCS) guidato dalla community. Ti offrono un vocabolario condiviso con auditor e ufficio acquisti.
Il grande equivoco
Un mito diffuso è che “private cloud significhi OpenStack” o che “serva Proxmox”. Nessuna delle due cose è vera. Private cloud e IaaS sono categorie, non prodotti. La domanda giusta non è quale strumento, ma quale control plane si adatta alla tua scala, al tuo team e alla tua postura di compliance. Esistono almeno tre architetture credibili, e un sovereign cloud può essere costruito su una qualsiasi di esse.
Modo 1: un control plane IaaS completo
È il classico modello “costruisci il tuo cloud”: un control plane astrae compute, storage e networking aggregati in un’infrastruttura self-service e multi-tenant con API, quote e tenancy. È adatto a parchi infrastrutturali più grandi, ai service provider e ai team che hanno davvero bisogno di elasticità cloud sul proprio hardware.
Le opzioni open source in questa categoria includono:
- OpenStack - il control plane IaaS più completo, ora sotto la OpenInfra Foundation (entrata nella Linux Foundation nel 2025). La spina dorsale di molti sovereign cloud europei.
- Apache CloudStack - un IaaS maturo e più semplice da gestire, dell’Apache Software Foundation.
- OpenNebula - leggero, ottimo per l’edge e per private cloud di medie dimensioni.
- Sovereign Cloud Stack (SCS) - standard aperti e implementazione di riferimento concepiti appositamente per la sovranità, spesso costruiti sopra OpenStack e Kubernetes.
OpenStack è spesso la principale alternativa a VMware per le organizzazioni che vogliono un IaaS completo senza lock-in di licenza.
Modo 2: uno stack hypervisor o HCI
Se gestisci principalmente macchine virtuali e preferisci la semplicità operativa all’elasticità da hyperscale, uno stack hypervisor o iperconvergente è spesso la scelta migliore. Ti dà il ciclo di vita delle VM, clustering e storage senza il peso operativo di un control plane IaaS completo.
- Proxmox VE - piattaforma open source di virtualizzazione e HCI molto popolare, KVM più LXC, sempre più usata come sostituto di VMware.
- oVirt - l’upstream della gestione della virtualizzazione enterprise, basato su KVM.
- XCP-ng - l’hypervisor aperto basato su Xen (XAPI), un’alternativa diretta per gli utenti di Citrix Hypervisor.
- Harvester - HCI costruito su Kubernetes e KubeVirt, ponte verso il Modo 3.
Sotto tutti questi ci sono le stesse fondamenta Linux: KVM e libvirt per gli stack basati su KVM, lo Xen Project per XCP-ng e Ceph come livello di storage software-defined di riferimento.
Modo 3: Kubernetes-native, dove Kubernetes è il cloud
Un pattern in crescita consiste nel saltare del tutto un layer IaaS tradizionale e fare di Kubernetes stesso il cloud. I container sono l’unità primaria e le VM girano all’interno di Kubernetes quando serve. Si adatta alle organizzazioni cloud-native e ai team di platform engineering.
- KubeVirt - esegue le VM come workload Kubernetes di prima classe, accanto ai container.
- OpenShift Virtualization (e il suo upstream OKD Virtualization) - distribuzione enterprise della stessa idea.
- Cluster API (CAPI) - ciclo di vita dichiarativo dei cluster, trattando gli stessi cluster come risorse gestite.
- Harvester, Incus - opzioni HCI e di system container che completano questo modello.
Qui il “control plane” è la Kubernetes API stessa, con il più ampio ecosistema CNCF (Cilium per il networking, Rook/Ceph o Longhorn per lo storage, OpenBao o Vault per i secret) a coprire il resto.
Come scegliere
Non esiste un vincitore universale. Una guida di massima:
- Parco multi-tenant di grandi dimensioni o scala da service provider: orientati verso OpenStack / CloudStack / SCS (Modo 1).
- Carichi di lavoro incentrati sulle VM, team più piccolo, time-to-value rapido: orientati verso Proxmox VE / oVirt / XCP-ng (Modo 2).
- Cultura cloud-native, container-first, da platform engineering: orientati verso un approccio Kubernetes-native KubeVirt / Harvester (Modo 3).
- Molti ambienti reali sono ibridi, per esempio OpenStack per lo IaaS con Kubernetes in esecuzione sopra.
I layer attorno al control plane
In qualunque modo tu costruisca, la sovranità dipende dai layer di supporto, e anche questi sono open source-first:
- Storage: Ceph, Rook, Longhorn, MinIO (compatibile S3) - i tuoi dati, sul tuo hardware, via CSI e l’API S3.
- Networking e sicurezza: Cilium (eBPF), Calico, WireGuard, più identità zero-trust con SPIFFE/SPIRE e mTLS.
- Secret e chiavi: OpenBao o HashiCorp Vault per BYOK/HYOK.
- Infrastructure as Code: OpenTofu, Terraform, Pulumi, Crossplane, Ansible e Nix, così che l’intera piattaforma sia riproducibile e verificabile.
- GitOps e delivery: Argo CD o Flux, con Tekton, GitHub Actions, GitLab CI o Jenkins per le build.
- Observability: OpenTelemetry, Prometheus e lo stack Grafana LGTM, tutti su standard aperti così che la telemetria resti portabile.
Questi standard aperti (Kubernetes API, OCI, CSI/CNI, OpenTelemetry, S3) sono ciò che mantiene un sovereign cloud davvero portabile, invece di renderlo una nuova forma di lock-in.
FAQ
Il sovereign cloud è la stessa cosa della residenza dei dati?
No. La residenza dei dati significa che i tuoi dati risiedono in una regione scelta. La sovranità aggiunge controllo delle chiavi, controllo operativo, protezione giurisdizionale e portabilità.
Devo per forza usare OpenStack per essere sovereign?
No. OpenStack è un’ottima opzione, ma anche Apache CloudStack, OpenNebula, Proxmox VE, oVirt, XCP-ng e gli stack Kubernetes-native (KubeVirt, Harvester) possono fare da base a un sovereign cloud.
L’open source è davvero sicuro per questo?
Sì, ed è di solito la scelta più sicura per la sovranità. L’open source è ispezionabile, evita il lock-in del vendor ed è sostenuto da una governance neutrale (Linux Foundation, CNCF, OpenInfra, Apache).
Posso eseguire AI privata in un sovereign cloud?
Sì. L’inferenza self-hosted (vLLM, Ollama, llama.cpp) con vector store (pgvector, Qdrant) e redazione dei PII (Presidio) ti permette di eseguire LLM privati e RAG dove prompt e pesi non lasciano mai il tuo ambiente.
Dove si inserisce il confidential computing?
Intel TDX e AMD SEV-SNP proteggono i dati in uso, così nemmeno l’operatore della piattaforma può leggere la memoria del workload. Utile per i carichi di lavoro a massima garanzia.
Costruiscilo con il partner giusto
Un sovereign cloud è una decisione di architettura, non l’acquisto di un prodotto, e la parte più difficile è abbinare l’approccio ai tuoi carichi di lavoro, alla tua scala e ai tuoi obblighi di compliance. Rapid Solutions è una società di consulenza ingegneristica e managed services (non un cloud provider) con uffici ad Amsterdam e Dubai. Progettiamo e gestiamo sovereign private cloud su tutto l’ecosistema open source, OpenStack e CloudStack, Proxmox VE e Harvester, o Kubernetes-native KubeVirt, con la residenza dei dati nell’UE disponibile come capacità e un principio semplice in tutto: i tuoi dati, le tue chiavi, il tuo controllo.
Che tu voglia costruire da zero o farci gestire in modalità sovereign ciò che già esegui, contatta Rapid Solutions per definire l’approccio giusto.