Kubernetes Cloud: servizi Cloud per Kubernetes, mini guida pratica

Amazon EKS, Google GKE e Azure AKS restano le piattaforme Kubernetes gestite dominanti – ma nel 2026 appaiono molto diverse rispetto a pochi anni fa.

I tre principali servizi Kubernetes gestiti – Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE) e Azure Kubernetes Service (AKS) – rappresentano ancora la stragrande maggioranza dei workload Kubernetes in produzione a livello mondiale. Se gestisci infrastruttura per clienti o esegui applicazioni containerizzate su larga scala, è molto probabile che tu stia già utilizzando almeno uno di essi.

Tutti e tre gestiscono gli aspetti fondamentali: il cloud provider si occupa del control plane (clustering etcd, alta disponibilità del server API, patching dei nodi master) così da permetterti di concentrarti sul deployment dei workload. Ma la definizione di “gestito” si è ampliata significativamente. Oggi ogni provider offre anche una modalità opinionata e altamente automatizzata che gestisce il data plane (nodi worker) – riducendo o addirittura eliminando la necessità di configurare, patchare e scalare i nodi manualmente. Comprendere queste differenze è essenziale per fare la scelta giusta della piattaforma.

Vediamo più da vicino ciascun servizio e cosa è cambiato.

Amazon Elastic Kubernetes Service (EKS)

Amazon EKS è disponibile al pubblico dal 2018 e si è evoluto in una piattaforma potente e flessibile, profondamente integrata con l’ecosistema AWS. EKS consente di eseguire applicazioni Kubernetes nelle regioni cloud AWS in tutto il mondo o on-premises tramite EKS Anywhere.

L’aggiunta recente più significativa è EKS Auto Mode, la risposta di AWS al Kubernetes completamente gestito. Auto Mode automatizza il provisioning, il patching e lo scaling del data plane utilizzando Karpenter e Bottlerocket sotto il cofano. Invece di gestire i tradizionali node group, AWS effettua il provisioning di nodi dimensionati correttamente on demand in base ai requisiti dei pod, gestisce il bin-packing e sostituisce i nodi automaticamente. Raggiunge un equilibrio tra automazione e la flessibilità che i team AWS-native si aspettano.

EKS ha inoltre introdotto le Pod Identities, un meccanismo semplificato per concedere ai pod un accesso sicuro ai servizi AWS – sostituendo nella maggior parte degli scenari la configurazione più vecchia e complessa di IRSA (IAM Roles for Service Accounts).

Un dettaglio di cui gli MSP dovrebbero essere consapevoli: AWS offre Extended Support per le versioni Kubernetes più vecchie, ma il costo passa da $0,10 a $0,60 per ora per cluster (un aumento di 6 volte). Per i team che gestiscono più cluster e che potrebbero non aggiornare tempestivamente, questo costo può accumularsi rapidamente. Restare su una versione supportata non è solo una best practice – è una decisione di controllo dei costi.

EKS resta ideale per le organizzazioni già investite nell’ecosistema AWS e per i team di piattaforma che desiderano un controllo granulare sull’infrastruttura. Il trade-off è una superficie operativa più complessa rispetto a GKE Autopilot o AKS Automatic, in particolare per quanto riguarda il networking VPC CNI e la configurazione IAM.

Google Kubernetes Engine (GKE)

Google Kubernetes Engine beneficia della posizione unica di Google come creatore di Kubernetes stesso. GKE segue le release upstream di Kubernetes più rapidamente dei suoi concorrenti – tipicamente entro due settimane tramite il canale di rilascio Rapid – e resta una delle piattaforme Kubernetes gestite più avanzate disponibili.

Il principale elemento differenziante di GKE è Autopilot, una modalità operativa completamente gestita e “nodeless”. Con Autopilot, definisci i tuoi pod e Google si occupa di tutto il resto: provisioning dei nodi, bin-packing, patching del sistema operativo, aggiornamenti e scaling. Paghi per la CPU, la memoria e lo storage effimero che i tuoi pod effettivamente richiedono, non per la capacità inattiva dei nodi. Questo modello elimina l’overprovisioning a livello di nodo ed è particolarmente conveniente per workload variabili o con picchi.

Autopilot è maturato considerevolmente e ora supporta GPU NVIDIA A100/H100 e TPU Google, rendendolo adatto anche per workload di inferenza e training AI/ML. GKE utilizza inoltre Dataplane V2, basato su eBPF, che gestisce il routing dei pacchetti e l’applicazione delle network policy direttamente nel kernel – bypassando completamente iptables per una migliore scalabilità con cluster di grandi dimensioni.

GKE offre Release Channel strutturati (Rapid, Regular, Stable) con aggiornamenti automatici. I cluster iscritti al canale Extended possono rimanere su una versione minore di Kubernetes più vecchia fino a circa 30 mesi, ma durante il periodo di supporto esteso si applica un costo aggiuntivo di gestione del cluster di $0,50 per cluster per ora. Questo costo non si applica ai cluster che utilizzano GKE Enterprise edition, che include il supporto esteso nel suo pricing per vCPU.

Il trade-off con Autopilot è una flessibilità ridotta: limita i container privilegiati, alcune configurazioni DaemonSet e gli strumenti personalizzati basati su eBPF. Se il tuo stack richiede accesso a livello kernel o capability Linux elevate, GKE Standard (la modalità tradizionale con nodi self-managed) è la scelta appropriata.

Azure Kubernetes Service (AKS)

Microsoft AKS è cresciuto fino a diventare una piattaforma completamente matura con un vantaggio significativo per i team attenti al budget: il control plane base di AKS è gratuito. Si paga solo per i nodi worker e le risorse associate, il che fa una differenza significativa per le organizzazioni che gestiscono molti cluster (uno scenario comune per gli MSP).

Lo sviluppo recente più rilevante è AKS Automatic, che ha raggiunto la disponibilità generale a settembre 2025. AKS Automatic è la visione di Microsoft di un’esperienza Kubernetes completamente gestita: applica configurazioni predefinite opinionated per sicurezza, scaling e networking out of the box, abbassando drasticamente la barriera operativa. Come GKE Autopilot ed EKS Auto Mode, automatizza la gestione dei nodi, ma preserva una maggiore flessibilità a livello Kubernetes rispetto ai guardrail più rigidi di Autopilot. AKS Automatic utilizza un SKU dedicato con un costo del control plane di $0,16 per ora per cluster – più alto del tier Standard a $0,10/ora, ma competitivo dato il livello di automazione incluso.

AKS è organizzato in tre tier: Free (control plane gestito, nessun SLA), Standard ($0,10/ora per cluster, SLA di uptime del 99,95% per cluster zone-redundant) e Premium (aggiunge Long-Term Support con fino a 24 mesi su versioni Kubernetes selezionate e gestione avanzata della flotta). L’opzione LTS del tier Premium è particolarmente rilevante per ambienti enterprise e MSP che necessitano di finestre di aggiornamento più lunghe.

AKS si integra strettamente con l’ecosistema Microsoft tramite Workload Identity con Entra ID per l’autenticazione sicura e senza secret dei pod alle risorse Azure, Azure Policy for AKS per l’applicazione della governance, e l’integrazione nativa con Azure DevOps e GitHub Actions per le pipeline CI/CD.

AKS è la scelta naturale per le organizzazioni che eseguono workload basati su Windows insieme a container Linux, e per i team che operano già all’interno dell’ecosistema Azure e Microsoft 365.

Confronto rapido

	EKS	GKE	AKS
Costo del control plane	$0,10/ora ($73/mese)	$0,10/ora (Standard e Autopilot)	Gratuito (base), $0,10/ora (Standard), $0,16/ora (Automatic), $0,60/ora (Premium)
Modalità completamente gestita	EKS Auto Mode	GKE Autopilot	AKS Automatic
Adozione nuove versioni K8s	4-8 settimane dopo l’upstream	1-2 settimane (canale Rapid)	3-6 settimane
Supporto esteso	+12 mesi ($0,60/ora totali, vs $0,10/ora standard)	Fino a 30 mesi ($0,50/ora extra; gratuito con Enterprise edition)	Fino a 24 mesi (tier Premium)
Opzione serverless/nodeless	Fargate (per pod), Auto Mode	Autopilot (completamente nodeless)	AKS Automatic
Più adatto per	Team AWS-native, massima flessibilità	Aggiornamenti più rapidi, workload AI/ML	Attento ai costi, ecosistema Microsoft

L’ascesa del Kubernetes “No-Ops”

La tendenza più importante nel Kubernetes gestito negli ultimi due anni è lo spostamento verso quelle che molti chiamano modalità “No-Ops”. GKE Autopilot ha aperto la strada a questo approccio, e sia EKS Auto Mode che AKS Automatic hanno seguito. La premessa è la stessa: il provider gestisce l’intero ciclo di vita dell’infrastruttura in modo che i team di piattaforma possano concentrarsi esclusivamente sui workload.

Per MSP e sysadmin che gestiscono Kubernetes per più clienti, queste modalità agiscono come un moltiplicatore di forza. Invece di patchare nodi, ottimizzare AMI e gestire configurazioni dell’autoscaler per ogni cluster, definisci le specifiche dei pod e lasci che il provider gestisca il resto. Il trade-off è una minore personalizzazione a livello di nodo, ma per la maggior parte dei workload standard è un compromesso che vale la pena accettare.

Vale la pena sottolineare che “No-Ops” non significa “nessuna responsabilità”. Sei ancora responsabile del dimensionamento delle resource request, della sicurezza a livello applicativo, delle network policy e della pianificazione degli aggiornamenti. L’automazione redistribuisce il carico operativo; non lo elimina.