Centottantadue miliardi di dollari. È la cifra che le aziende di tutto il mondo hanno bruciato nel 2026 in risorse cloud inutilizzate — il 27% della spesa globale, una percentuale che non si schioda dal 2019 nonostante l’82% delle organizzazioni dichiari l’ottimizzazione dei costi come priorità assoluta. Fa quasi ridere, se non fosse che dietro quei numeri c’è una macchina perfettamente oliata che trasforma la complessità infrastrutturale in profitto per tre aziende: Amazon, Google e Microsoft. Kubernetes, il sistema di orchestrazione dei container nato in casa Google e poi “donato” alla comunità open source, è diventato lo standard de facto per gestire applicazioni su larga scala. Il problema — quello che nessun evangelista del cloud ti dirà mai alla conferenza di turno — è che questo standard porta con sé una tassa nascosta che nessuno mette a bilancio, e che qualcuno incassa con puntualità svizzera.
I cluster Kubernetes gestiti dai tre grandi provider costano un fisso per ogni piano di controllo attivo. Amazon EKS chiede 0,10 dollari l’ora per cluster: sembrano niente, ma per un’organizzazione con 50 cluster tra sviluppo, staging e produzione fanno 43.800 dollari l’anno solo di control plane, prima ancora di eseguire un singolo container. Moltiplicato per migliaia di aziende in tutto il mondo, il conto diventa un fiume di denaro che scorre silenziosamente verso Seattle. E i costi del control plane sono solo la punta dell’iceberg: ci sono le tariffe di trasferimento dati (fino a 0,09 dollari per gigabyte su AWS), i piani di supporto enterprise che arrivano a 15.000 dollari al mese, gli strumenti di monitoraggio proprietari che nessuno ti dice essere opzionali. La vera domanda non è come risparmiare qualche dollaro — è perché l’architettura dominante sia strutturalmente progettata per costare così tanto.
Le risposte esistono, e vengono — guarda caso — dal mondo open source. Strumenti come vCluster, Kamaji e k0smotron stanno riscrivendo le regole del multi-tenancy su Kubernetes, eliminando quella tassa invisibile che i cloud provider hanno tutto l’interesse a mantenere. Ma per capire cosa c’è davvero in gioco bisogna guardare il quadro completo: chi guadagna dalla complessità, chi offre alternative, e soprattutto — chi ha il potere in questa storia.
Il business della complessità: 182 miliardi in fumo e qualcuno ringrazia
I numeri sono brutali e vale la pena metterli tutti in fila. Nel 2026 la spesa globale per il cloud ha toccato i 675 miliardi di dollari. Di questi, 182 miliardi — oltre un quarto — sono finiti in risorse che nessuno usa: calcolo inattivo per il 35%, istanze sovradimensionate per il 25%, storage scollegato per il 15%, snapshot orfani per il 10%. Non sono errori sporadici di qualche sysadmin distratto: è un pattern strutturale che si ripete identico da sette anni, da quando qualcuno ha iniziato a misurarlo con sistematicità. La CNCF ha rilevato che i cluster Kubernetes utilizzano in media il 10% della CPU e il 20% della memoria allocata. Detto in parole povere: per ogni dieci server virtuali pagati, uno lavora davvero. Gli altri nove stanno lì a generare fatture.
Qui il discorso si fa politico, perché questa inefficienza non è un bug del sistema — è una feature. I cloud provider hanno costruito un modello di business che premia la complessità: più cluster servono, più piani di controllo si attivano, più la fattura mensile cresce. Amazon detiene oltre il 60% del mercato container e Kubernetes, con EKS che da solo copre il 30% della torta globale con 2 milioni di clienti. Google e Microsoft si spartiscono il resto, in una competizione che non riguarda chi offre il servizio migliore, ma chi riesce a intrappolare più clienti nel proprio ecosistema. Il vendor lock-in non è un effetto collaterale: è il prodotto. L’89% delle aziende dichiara di adottare una strategia multi-cloud, e il 42% lo fa esplicitamente per sfuggire al lock-in — ma dichiararlo e farlo sono due cose molto diverse, perché ogni provider costruisce il suo Kubernetes con integrazioni proprietarie che rendono la migrazione un incubo costoso.
Il punto è che Kubernetes doveva essere la grande promessa di portabilità. Un’astrazione universale che funziona ovunque, open source, neutrale, governata dalla Cloud Native Computing Foundation. Sulla carta è tutto vero. Nella pratica, provare a spostare un carico di lavoro da EKS a GKE significa rifare le configurazioni di rete, riscrivere le policy IAM, adattare lo storage, rivalidare i certificati — settimane di lavoro ingegneristico e migliaia di dollari buttati. Google ha inventato Kubernetes e poi lo ha regalato al mondo, ma non certo per generosità: lo ha fatto per creare uno standard che rendesse il cloud un mercato aperto invece di un monopolio IBM. Il risultato, con un’ironia che non sfugge a chi conosce la storia dell’informatica, è che quello standard aperto è diventato il veicolo perfetto per tre nuovi monopoli. La portabilità promessa si è trasformata nella portabilità di pagare chiunque dei tre, a patto di non provare a cambiare fornitore.
La situazione peggiora quando si aggiunge l’intelligenza artificiale al quadro. L’utilizzo medio delle GPU nei cluster cloud è del 23% — il che significa che il 77% della capacità GPU più costosa e richiesta al mondo sta ferma a scaldare aria nei data center di qualcun altro. Un report di SiliconANGLE della scorsa settimana lo ha detto senza mezzi termini: il provisioning di un ambiente GPU dedicato richiede più di tre settimane in molte organizzazioni enterprise, e nel frattempo chip che costano decine di migliaia di dollari restano inattivi. Le GPU sono diventate la categoria di spreco in più rapida crescita nel 2025-2026. Per le Big Tech è un problema che si traduce in fatture più salate; per chi cerca di innovare senza essere schiacciato dalla concentrazione del potere tecnologico, è un muro altissimo.
Cluster virtuali: la risposta open source che nessun provider pubblicizza
Se la complessità è il prodotto, la semplificazione è un atto sovversivo. I cluster virtuali sono esattamente questo: una tecnologia che permette di creare decine di ambienti Kubernetes completamente isolati all’interno di un singolo cluster fisico, eliminando la necessità di pagare un piano di controllo separato per ciascuno. Il concetto è lo stesso che ha rivoluzionato i server negli anni Duemila con la virtualizzazione hardware — prima di VMware, ogni applicazione aveva bisogno della sua macchina fisica, con tutti i costi e gli sprechi che ne derivavano. I cluster virtuali applicano la stessa logica a Kubernetes: un’infrastruttura condivisa sotto, tanti ambienti logici separati sopra, un solo punto di gestione operativa. La differenza fondamentale è che stavolta gli strumenti sono open source, e questo cambia le dinamiche di potere.
vCluster è il più maturo di questi strumenti, sviluppato da Loft Labs — che a inizio 2026 ha cambiato nome in vCluster Labs, segno di quanto il progetto sia diventato l’identità stessa dell’azienda. Funziona creando un cluster virtuale come un insieme di pod dentro un namespace del cluster ospite. Ogni cluster virtuale ha il suo API server, il suo scheduler, il suo controller manager — dal punto di vista dello sviluppatore che lo usa, è un Kubernetes vero e proprio in tutto e per tutto, senza cuciture visibili verso il cluster sottostante. Ma sotto il cofano gira su risorse condivise, e il piano di controllo non costa nulla di aggiuntivo. Un team che prima spendeva 43.800 dollari l’anno in control plane per 50 cluster può passare a un singolo cluster fisico con 50 cluster virtuali, portando quel costo quasi a zero. Il progetto è su GitHub con licenza open source, ha superato le 8.000 stelle, e la community è attiva: l’ultimo commit risale al 27 marzo 2026, due giorni fa. Il codice si muove, non è un progetto abbandonato in qualche cassetto digitale.
Kamaji merita una menzione speciale perché nasce da Clastix, un’azienda con radici italiane. L’approccio è diverso da vCluster: invece di virtualizzare dentro un namespace, Kamaji sposta i piani di controllo in un cluster di gestione centralizzato dove girano come normali pod. La metafora giusta è quella del colocation: il gestore dell’infrastruttura si occupa del fisico, il cliente gestisce il suo spazio — con la differenza che qui gli “spazi” sono API server Kubernetes condivisi sopra un unico cluster etcd con prefissi separati per ogni tenant. È la soluzione ideale per chi offre Kubernetes come servizio gestito senza voler moltiplicare l’hardware sottostante. L’integrazione nativa con Cluster API — lo standard per la gestione dichiarativa dei cluster — ne fa uno strumento pronto per la produzione, non un esperimento accademico. Per chi crede che l’innovazione tecnologica non debba nascere solo nella Silicon Valley, Kamaji è un esempio concreto di come le alternative open source possono arrivare da qualsiasi parte del mondo.
k0smotron completa il trittico puntando sull’automazione infrastrutturale e sugli scenari ibridi. Costruito sopra k0s, gestisce piani di controllo ospitati come risorse native di Kubernetes con integrazione completa di Cluster API fin dalla progettazione iniziale. Il suo punto di forza è il supporto per architetture distribuite: i piani di controllo vivono in un data center centrale, i nodi worker possono stare ovunque — uffici remoti, postazioni edge, cloud diversi — senza bisogno di VPN o link privati tra i siti. Per i team che hanno già adottato GitOps, k0smotron si inserisce nella pipeline esistente senza stravolgimenti: tutto è dichiarato in YAML, versionato in Git, riconciliato automaticamente dai controller Kubernetes. Nessuno dei tre strumenti è una soluzione universale, e non pretendono di esserlo: vCluster eccelle negli ambienti effimeri per sviluppatori, Kamaji nel multi-tenancy enterprise di produzione, k0smotron nell’ibrido e nell’edge. Ma insieme coprono praticamente ogni scenario in cui un cluster dedicato sembrava l’unica opzione — e ogni cluster dedicato in meno è una fattura in meno verso Bezos, Pichai o Nadella.
GPU, intelligenza artificiale e il nuovo feudalesimo digitale
La partnership annunciata il 26 marzo tra QumulusAI e vCluster Labs racconta bene dove sta andando il mercato — e dove rischia di arenarsi. Le due aziende hanno creato un AI Infrastructure Lab per sviluppare ambienti Kubernetes isolati su infrastruttura GPU condivisa, con hardware NVIDIA Blackwell B300 e RTXPRO 6000, il top di gamma attuale per training e inferenza AI. L’obiettivo dichiarato è permettere agli sviluppatori di creare ambienti di lavoro in minuti invece che in settimane, massimizzando l’utilizzo di GPU che altrimenti resterebbero inattive per tre quarti del tempo. Al KubeCon Europe 2026, vCluster Labs ha presentato anche Private Nodes, Auto Nodes con autoscaling basato su Karpenter, e integrazioni dirette con NVIDIA Base Command Manager. Sulla carta è tutto promettente: meno sprechi, più accessibilità, infrastruttura condivisa in modo intelligente.
Ma c’è un aspetto che merita uno sguardo più critico, e non è un dettaglio. Il fatto che servano partnership commerciali per rendere accessibile un’infrastruttura che potrebbe — e dovrebbe — essere un bene comune dice molto sullo stato attuale della tecnologia. Le GPU di fascia alta, quelle che servono davvero per addestrare modelli AI competitivi, costano decine di migliaia di dollari ciascuna e sono prodotte da un’unica azienda al mondo: NVIDIA. La concentrazione è impressionante e preoccupante: un solo fornitore hardware al vertice, tre grandi cloud provider che ne controllano l’accesso alla base, e in mezzo un ecosistema di startup che cercano di democratizzare quel che resta costruendo strati di astrazione sopra strati di astrazione. È una torre di complessità in cui ogni livello aggiunge il suo margine di profitto, e alla base c’è sempre lo stesso silicio prodotto a Taiwan. Chi ha parlato di feudalesimo digitale ha colto il punto: pochi signori controllano la terra — l’hardware, i data center, la fibra ottica — e tutti gli altri pagano l’affitto per coltivarla.
Il nocciolo della questione è questo: gli strumenti open source come vCluster sono genuinamente utili e riducono davvero i costi per chi li adotta. Non è in discussione. Ma non risolvono il problema di fondo, che è politico prima che tecnico. Puoi virtualizzare quanto vuoi, puoi ottimizzare la spesa cloud fino all’ultimo centesimo con i migliori strumenti FinOps sul mercato, ma alla fine della catena stai comunque pagando Amazon, Google o Microsoft per eseguire il tuo codice sul loro hardware, nei loro data center, secondo le loro condizioni contrattuali che cambiano quando vogliono loro. L’alternativa vera — quella che fatica a emergere nel dibattito dominato dal pragmatismo aziendale e dalla rassegnazione — è l’infrastruttura autogestita: cooperative di calcolo, data center comunitari, cloud federati gestiti da enti pubblici o collettivi tecnologici. Progetti come Hetzner in Germania, OVHcloud in Francia, o l’iniziativa GAIA-X europea vanno timidamente in questa direzione, anche se con tutti i limiti di chi nuota controcorrente in un oceano dominato da pesci con capitalizzazioni trilionarie.
Serve onestà intellettuale, però. La maggior parte delle organizzazioni non può permettersi di uscire dal cloud delle Big Tech domani mattina. Le competenze richieste per gestire Kubernetes in autonomia sono enormi — e non a caso, visto che la complessità del sistema è funzionale al business di chi vende la gestione come servizio. I costi di un data center proprio sono proibitivi per aziende medio-piccole italiane ed europee, e la velocità di innovazione dei provider gestiti è oggettivamente difficile da replicare con risorse limitate. Ma questo non significa accettare lo status quo come inevitabile o, peggio, come desiderabile. Ogni cluster virtualizzato con vCluster invece che comprato come servizio gestito è un pezzo di indipendenza conquistata. Ogni competenza sviluppata internamente su strumenti open source è un investimento in sovranità tecnologica che non si svaluta quando il provider decide di aumentare i prezzi — e li aumenta sempre, è un pattern documentato quanto lo spreco. La questione di fondo non è se sia possibile un’alternativa ai tre signori del cloud, ma quanto siamo disposti a investire per costruirla, dal basso, senza aspettare che qualcuno ce la conceda dall’alto. La storia della tecnologia insegna che le alternative nascono sempre dove nessuno se le aspetta: nei garage, nelle comunità, nei collettivi. Mai nei consigli di amministrazione.
I 182 miliardi di sprechi cloud annuali non sono un fallimento dell’ottimizzazione tecnica — sono il risultato prevedibile di un mercato costruito sull’asimmetria informativa, sulla dipendenza strutturale e sull’interesse dei fornitori a mantenere i clienti nell’ignoranza dei costi reali. I cluster virtuali offrono un’uscita parziale ma concreta, una riduzione dei costi che restituisce margine di manovra ai team tecnici e lo sottrae — anche se di poco — ai provider. Ma la partita vera si gioca altrove, fuori dai terminali e dai file YAML: nella capacità delle comunità tecniche di costruire infrastrutture alternative, nella volontà politica di trattare il digitale come un bene pubblico, e nella consapevolezza che ogni dollaro risparmiato con uno strumento open source è un dollaro in meno nel bilancio di chi usa la nostra dipendenza come modello di business.
Domande frequenti
Quanto costa un cluster Kubernetes gestito nel 2026?
Amazon EKS addebita 0,10 dollari l’ora per cluster, circa 72 dollari al mese o 876 dollari all’anno per singolo cluster. Azure AKS offre il piano di controllo gratuito, mentre Google GKE è gratuito per il primo cluster zonale e costa 0,10 dollari l’ora per i cluster aggiuntivi o regionali. A questi vanno sommati i costi di trasferimento dati (fino a 0,09 dollari per GB), i nodi worker, lo storage e gli eventuali piani di supporto — la fattura reale è sempre significativamente più alta del costo base del control plane.
Cosa sono i cluster virtuali Kubernetes e come funzionano?
Un cluster virtuale è un ambiente Kubernetes completo — con il proprio API server, scheduler e controller manager — che gira come un insieme di pod all’interno di un namespace su un cluster fisico ospite. Per lo sviluppatore che lo utilizza è indistinguibile da un cluster reale, ma non richiede un piano di controllo dedicato né hardware aggiuntivo. I pod vengono effettivamente eseguiti sui nodi del cluster ospite attraverso un livello di sincronizzazione, consolidando l’utilizzo delle risorse e mantenendo l’isolamento a livello API.
vCluster è gratuito e open source?
Il core di vCluster è open source con licenza Apache 2.0, disponibile su GitHub e utilizzabile gratuitamente. vCluster Labs — l’azienda dietro il progetto, che fino a inizio 2026 si chiamava Loft Labs — offre anche una piattaforma commerciale con funzionalità aggiuntive per la gestione enterprise, come interfaccia grafica, controllo accessi avanzato e gestione centralizzata. Il modello è quello classico dell’open core: il motore è libero, le funzionalità di governance e gestione aziendale sono a pagamento.
Qual è la differenza tra vCluster, Kamaji e k0smotron?
vCluster crea cluster virtuali come pod dentro namespace ed è pensato per ambienti di sviluppo effimeri, test di integrazione e isolamento delle Custom Resource Definition. Kamaji ospita i piani di controllo come pod in un cluster di gestione centralizzato ed è ideale per provider di servizi Kubernetes gestiti e infrastrutture multi-tenant di produzione. k0smotron gestisce piani di controllo come risorse Kubernetes native con integrazione nativa di Cluster API, ed è la scelta migliore per deployment ibridi, edge e team che usano GitOps. I tre strumenti non sono in competizione: possono coesistere nella stessa organizzazione per scenari diversi.
Come si riduce il vendor lock-in nei servizi Kubernetes cloud?
Le strategie principali sono tre: adottare strumenti open source e standard aperti (come Cluster API) per la gestione dei cluster, evitando integrazioni proprietarie specifiche del provider; investire in competenze interne sulla gestione di Kubernetes vanilla invece di dipendere esclusivamente dai servizi gestiti; e valutare provider cloud europei o indipendenti come Hetzner, OVHcloud o Scaleway, che offrono servizi Kubernetes a costi inferiori e con minore rischio di lock-in nelle piattaforme dei colossi americani. I cluster virtuali contribuiscono a questa strategia riducendo la dipendenza dai piani di controllo gestiti dai provider.