Amazon EKS

Il problema che risolve

Kubernetes è composto da due componenti: il control plane, cioè l'API server, lo scheduler, i controller e il database etcd che conserva lo stato del cluster, e i nodi, le macchine su cui girano i container. Installare il control plane è questione di un pomeriggio. Manutenere un cluster in alta affidabilità è un progetto complesso: vanno considerati ridondanza, backup, certificati e aggiornamenti di versione.

Un servizio Kubernetes gestito come Amazon EKS si fa carico del componente control plane di Kubernetes. AWS esegue quindi il control plane su più Availability Zone, lo aggiorna, ne garantisce la disponibilità con uno SLA e lo espone come un servizio. Il cluster che ne risulta è Kubernetes certificato: gli stessi manifest, gli stessi strumenti, gli stessi operatori che girano ovunque.

Non è detto che sia la soluzione adatta a tutti. Un team piccolo, con una manciata di servizi e nessuna esperienza Kubernetes, può orientarsi su Amazon ECS, che non ha costi di control plane e non impone il ritmo degli aggiornamenti, o utilizzare funzioni Lambda. EKS ha senso quando il team conosce già Kubernetes o lo vuole apprendere, quando l'ecosistema che gli gira intorno (operatori, GitOps, Helm) fa parte del progetto, o quando si vuole mantenere un livello di portabilità o interoperabilità verso altri cloud o verso il datacenter.

Responsabilità condivise

Nel modello standard AWS gestisce l'API server, etcd e le interfacce di rete che collegano il control plane alla vostra VPC. Tutto il resto rimane in mano all'operatore: i nodi EC2 e il loro sistema operativo, i componenti di rete e storage installati nel cluster (gli add-on), la VPC con le sue subnet, la mappatura fra le identità IAM e i permessi Kubernetes, e soprattutto gli aggiornamenti dei nodi, che non seguono da soli quelli del control plane. È una divisione più sbilanciata di quanto la parola «gestito» lasci intendere, e il modo consolidato di gestirla è affidare i nodi ai node group gestiti.

Dal dicembre 2024 AWS propone anche EKS Auto Mode, ed è la strada su cui spinge per i cluster nuovi. In questa modalità AWS prende in carico anche i nodi, dal sistema operativo alle patch. I nodi sono istanze EC2 che AWS tratta come cattle: sistema operativo Bottlerocket immutabile, nessun accesso SSH, sostituzione automatica entro 21 giorni dalla creazione.

Fargate, la modalità serverless, esegue ogni pod in una micro-VM dedicata, senza nodi da vedere o gestire esplicitamente. Ha limiti netti: niente DaemonSet, niente GPU, niente container privilegiati, solo subnet private. Resta un'opzione per casi specifici, e AWS sta spingendo su Auto Mode come rimpiazzo.

	Node group gestiti	EKS Auto Mode	Fargate
Chi gestisce i nodi	Operatore	AWS	Nessun nodo: un pod per micro-VM
Aggiornamenti dei nodi	Avviata dall'operatore	Automatici, entro 21 giorni	Al riavvio del pod
Cosa si paga	EC2	EC2 più una tariffa di gestione	vCPU e memoria del pod
Limiti	Il lavoro operativo	Nessun accesso ai nodi	Niente DaemonSet, GPU, container privilegiati

Come funziona

Il plugin di rete predefinito, VPC CNI, assegna a ogni pod un indirizzo della VPC. È una scelta che semplifica security group e debugging, e che consuma indirizzi in fretta: va messa in conto quando si disegnano le subnet. Un Service o un Ingress diventano un Network o un Application Load Balancer, ciascuno con il suo costo. Dall'ottobre 2026 Auto Mode supporta anche la Gateway API.

Le identità viaggiano su due binari distinti. Chi amministra il cluster entra con le proprie credenziali IAM, mappate sui ruoli Kubernetes attraverso le access entry. I pod che devono chiamare servizi AWS ricevono un ruolo IAM con EKS Pod Identity, senza chiavi salvate nel cluster. Lo storage è EBS per i volumi a blocchi ed EFS per i file system condivisi, tramite i rispettivi driver CSI.

Aggiornamenti di versione

La community rilascia una minor version di Kubernetes ogni quattro mesi circa, ed EKS segue l'upstream. Ogni nuova versione ha 14 mesi di supporto standard e successivamente 12 mesi di supporto esteso (a pagamento). Alla fine dei 26 mesi AWS aggiorna il control plane per conto suo, senza preavviso, e lascia nodi e add-on dove sono. Per restare all'interno del supporto standard è quindi necessario fare circa tre aggiornamenti all'anno.

Il grosso del lavoro sta nei nodi e negli add-on. Ogni aggiornamento del control plane va seguito da quello dei node group, della VPC CNI, di CoreDNS, di kube-proxy e dei driver CSI, e preceduto da una verifica che i manifest non usino API rimosse. EKS aiuta con gli upgrade insight, che segnalano le API deprecate in uso e bloccano l'aggiornamento se trovano problemi, e dal luglio 2026 un aggiornamento si può annullare entro sette giorni. Con Auto Mode i nodi seguono il control plane da soli, nel rispetto dei Pod Disruption Budget.

Nello stimare il costo di un cluster EKS va prestata particolare attenzione ai servizi accessori, che fanno lievitare il prezzo base: i NAT Gateway, il traffico fra Availability Zone, un load balancer per ogni Service esposto, i log in CloudWatch. Su un cluster piccolo pesano più del canone base del control plane.

AWS in Italia

AWS ha una region a Milano dal 2020 (eu-south-1), con tre Availability Zone, ed EKS è disponibile. Per chi ha vincoli di data residency la regione di Milano può rivelarsi interessante, con un'avvertenza: le region più piccole ricevono i nuovi tipi di istanza e i servizi più recenti con qualche mese di ritardo rispetto a Francoforte o all'Irlanda, e conviene verificare caso per caso.

Adozione

Nei progetti di adozione di EKS seguo di solito questi passi:

1. L'account e la rete prima del cluster. Strutturazione degli account con AWS Organizations, controllo di accesso per gli utenti in SSO, progettazione delle VPC con subnet dimensionate opportunamente, accesso privato e protetto all'API server. Rimettere mano a questi componenti successivamente rischia di diventare impraticabile.
2. Tutto in Terraform (o in un'altra tecnologia di Infrastructure as Code), cluster compreso, senza eccezioni per le cose «fatte una volta sola».
3. Node group gestiti, con immagini Bottlerocket o Amazon Linux 2023. Auto Mode lo valuto caso per caso.
4. Rilasci in GitOps e observability dal primo giorno, e non quando il primo incidente li rende urgenti.
5. Un calendario degli aggiornamenti, con un responsabile e una finestra ogni quattro mesi.

EKS o GKE?

I due servizi si assomigliano molto. Google Kubernetes Engine aggiorna da solo control plane e nodi secondo un canale di rilascio, mentre su EKS l'aggiornamento è avviato dall'operatore o viene affidato ad Auto Mode. GKE Autopilot fattura le risorse richieste dai pod, EKS Auto Mode le istanze EC2 più una tariffa di gestione. L'identità su GKE si appoggia direttamente a IAM di Google, su EKS passa da una mappatura esplicita. La scelta si fa generalmente considerando il resto dell'infrastruttura e gli obiettivi a lungo termine.

Maturità

Lavoro su AWS e su EKS da anni, come cloud architect e come consulente Kubernetes, e lo considero la scelta di default per chi ha già deciso di stare su AWS e ha bisogno di Kubernetes. Il servizio è maturo, e il lavoro operativo sui nodi, che un tempo pesava sui team piccoli, oggi si riduce a poche decisioni iniziali e a un calendario rispettato. Il punto delicato resta il primo: capire se Kubernetes serve davvero. Di questo, e di come impostare l'infrastruttura AWS intorno al cluster, parlo nelle pagine sulla consulenza cloud e sulla consulenza Kubernetes.