ECS o EKS? Come scegliere l'orchestratore AWS senza pagare l'errore
Devi mettere in produzione dei container su AWS e la scelta è tra ECS, il servizio proprietario di Amazon, ed EKS, il Kubernetes gestito. La decisione sbagliata non si vede il primo giorno: la vedi in fattura dopo un anno, o nel momento in cui cerchi persone che sanno mantenere il sistema. Ecco i criteri per decidere bene.
La domanda è ricorrente nei progetti, e di solito arriva con una premessa sbagliata: che ECS ed EKS siano due modi equivalenti di fare la stessa cosa e la scelta dipenda dal gusto tecnico. Sono invece due prodotti con filosofie diverse, e la scelta giusta dipende quasi sempre dalla squadra che hai, più che dal carico di lavoro. Vediamo costi, competenze, sicurezza, e infine un criterio decisionale pratico.
Cosa sono, in due frasi
Amazon ECS è l'orchestratore proprietario di AWS: gestisci container con le sue astrazioni (task, servizi, cluster), si integra con gli altri servizi AWS senza strati intermedi, e il piano di controllo non costa nulla. Amazon EKS è Kubernetes gestito: il software è quello standard dell'ecosistema, con tutto ciò che comporta in termini di portabilità, strumenti e comunità, ma il piano di controllo lo paghi e la piattaforma va mantenuta.
Entrambi possono girare sui nodi EC2 o su Fargate, il calcolo serverless di AWS dove paghi al secondo e non gestisci macchine. Su questo terreno i due servizi sono più vicini di quanto si pensi, e proprio le differenze di Fargate nascondono una delle trappole di costo più importanti. Ci arriviamo.
I costi: la lista nascosta
Il primo numero che tutti citano è la quota di gestione del cluster: EKS costa dieci centesimi all'ora per cluster, circa settantatre dollari al mese, mentre su ECS la quota non esiste. Su dieci cluster la differenza è di settecento dollari al mese, che per molti progetti è rumore. La quota fissa, in effetti, è il costo meno interessante di tutta la lista.
I numeri che pesano di più sono altrove. Il calcolo sottostante costa uguale sui due servizi, quindi la vera domanda è come lo compri. I nodi con processori Graviton, l'architettura ARM di Amazon, costano circa il 20 per cento in meno dei corrispondenti x86 a parità di lavoro. Le istanze Spot, cioè capacità in eccedenza che AWS può interrompere con breve preavviso, arrivano a sconti tra il 60 e il 90 per cento per carichi che tollerano interruzioni: per ambienti di test e per molti microservizi è capacità quasi gratuita, letteralmente.
E qui la prima differenza che becca i team in contropiede: su ECS, Fargate ha una variante Spot con sconti fino al 70 per cento. Su EKS, no: i pod Fargate girano soltanto a tariffa piena. In più, Fargate costa comunque più dei nodi EC2 ben riempiti, tipicamente tra il 40 e il 60 per cento in più, perché il serverless ti vende comodità, non efficienza: ogni task paga la sua porzione intera, senza possibilità di impaccare carichi diversi sulla stessa macchina.
La seconda trappola si chiama Extended Support. Kubernetes rilascia versioni nuove a ritmo regolare, e AWS garantisce supporto standard per ciascuna per circa quattordici mesi. Se il cluster non viene aggiornato entro quel termine, entra automaticamente nel supporto esteso, dove la quota del control plane sale di sei volte: da dieci a sessanta centesimi l'ora, da circa 73 a circa 438 dollari al mese per cluster. Non è una sanzione esotica: le configurazioni di infrastruttura come codice spesso abilitano l'estensione di default, e team che non pianificano aggiornamenti semestrali la scoprono in fattura. Il messaggio è netto: con EKS gli upgrade di versione non sono un'opzione, sono una voce di budget.
Restano i costi di rete, uguali sui due servizi ma spesso ignorati in entrambi: il traffico tra zone di disponibilità diverse costa un centesimo per gigabyte in ciascuna direzione, e i gateway per uscire dalle subnet private si pagano a ora e a gigabyte. In architetture a microservizi chiacchierone, questa voce supera la quota del control plane. Va progettata, non subita.
Le competenze: il costo vero
Il costo che decide i progetti non è quello della fattura, è quello delle persone. ECS parla la lingua di AWS: task, servizi, ruoli IAM, integrazioni native. Un team che conosce bene l'ecosistema Amazon è produttivo su ECS in pochi giorni, e il servizio non aggiunge concetti nuovi da imparare né manutenzione di piattaforma.
EKS parla la lingua di Kubernetes, ed è un idioma ricco: manifesti YAML, Helm, operatori, CRD, RBAC di Kubernetes, più l'intera disciplina di gestire gli upgrade di versione senza fermare la produzione. Nessuna di queste cose è inutile: sono lo standard del settore, portabili tra cloud diversi e richieste dal mercato del lavoro. Ma hanno un costo di possesso che ECS non ha. La domanda onesta da farsi non è «conosciamo Kubernetes?» bensì «abbiamo qualcuno che mantiene Kubernetes nel tempo, con la sostituzione delle persone che questo implica?». Se la risposta è no, il prezzo del control plane è il costo minore del problema.
Per chi vuole Kubernetes senza tutto il mestiere, AWS ha introdotto EKS Auto Mode: il servizio automatizza provisioning dei nodi, scalatura e manutenzione, e i componenti di sistema girano nel piano gestito di AWS invece che sui tuoi nodi. Il prezzo della comodità è un sovrapprezzo di circa il 10-12 per cento sul costo delle istanze, più limiti che vanno conosciuti: niente accesso diretto ai nodi per diagnosticare, difficoltà con agenti legacy o moduli kernel particolari, e gli upgrade di versione del cluster restano comunque manuali. È una via di mezzo seria, non un pulsante magico.
Sicurezza: modelli diversi, vigilanza uguale
Entrambi i servizi sono sicuri di default quanto lo sei tu a configurarli. La differenza sta nel modello di identità. ECS separa in modo netto il ruolo con cui l'infrastruttura scarica l'immagine del container dal ruolo con cui il codice applicativo accede alle risorse AWS: una distinzione pulita che aiuta a dare a ogni componente solo i permessi che gli servono. EKS ha raggiunto un modello simile con Pod Identity, che ha semplificato molto la configurazione precedente.
Vale la pena conoscere un episodio recente, perché toglie ogni superficialità: nel 2025 è stata resa nota una vulnerabilità soprannominata ECScape, che su nodi EC2 consentiva a un container compromesso di rubare le credenziali dei task vicini sullo stesso host. Le mitigazioni esistono e sono documentate: isolamento più forte con Fargate, configurazioni restrittive della condivisione di processi, accessi ai metadati blindati. La lezione non è «ECS è insicuro», è che su nodi condivisi l'isolamento tra carichi va progettato e verificato, su qualunque orchestratore. Le buone pratiche di base restano le stesse: container che girano come utente non root, filesystem di root in sola lettura, permessi Linux ridotti al minimo.
Il criterio decisionale
Riassumo la scelta in una logica semplice, che funziona nella maggior parte dei casi.
Scegli ECS se il tuo progetto vive dentro AWS senza orizzonti di migrazione, se la squadra è piccola o non ha ingegneri di piattaforma dedicati, e se preferisci spendere il tempo di manutenzione sul prodotto anziché sull'infrastruttura. È la scelta della semplicità operativa, ed è vincente più spesso di quanto le discussioni sui social facciano credere: la maggior parte dei sistemi non ha bisogno di Kubernetes.
Scegli EKS se Kubernetes è già una competenza della casa, se la portabilità tra cloud e la libertà dall'ecosistema Amazon contano per la tua strategia, se hai bisogno di strumenti e operatori dell'ecosistema che non hanno equivalenti in ECS, o se lavori in organizzazioni dove «Kubernetes» è lo standard condiviso tra più team e più piattaforme. Con la condizione di mettere a budget sia le persone sia gli upgrade: un EKS senza manutenzione programmata è un debito con interessi al 600 per cento.
E un consiglio trasversale: qualunque cosa tu scelga, controlla a fine mese le voci che non stavi guardando. La fattura AWS non premia la scelta giusta tra ECS ed EKS, premia chi sa dove sta scorrendo il denaro: le zone di disponibilità, i gateway di rete, il Fargate comodo ma caro, e le versioni di Kubernetes scadute che continuano a correre in silenzio.
Se stai valutando questa scelta per un progetto reale e vuoi una seconda opinione sull'architettura prima di partire, scrivimi: è esattamente il tipo di decisione che costa poco prendere bene e tanto correggere dopo.
Fonti
Easter egg
La scelta più costosa dell'articolo può sembrare il control plane. Spesso è una riga dimenticata nel calendario degli upgrade.