Come funziona il modello di prezzo di Amazon EKS?
Amazon EKS applica una tariffa fissa di $0.10 all'ora per il control plane di ciascun cluster (circa $72 al mese). A questa si aggiunge il costo delle risorse AWS sottostanti (istanze EC2, Fargate, volumi EBS, load balancer) utilizzate per eseguire i worker node e le applicazioni. Il supporto esteso per le versioni meno recenti di Kubernetes costa $0.60 all'ora.
Comprendere il modello di prezzo di EKS è fondamentale per stimare con precisione le spese cloud ed evitare costi imprevisti. AWS offre diverse modalità operative per EKS, ciascuna con una propria struttura di costo. È necessario valutare le implicazioni di prezzo di cluster standard, managed node group, opzioni di auto scaling e componenti aggiuntivi opzionali. Analizzare questi componenti in anticipo garantisce una pianificazione efficace del budget e consente di ottimizzare i costi.
Questo articolo fa parte di una serie dedicata ai prezzi di Kubernetes.
In questo articolo:
- I componenti di prezzo di AWS EKS
- Costi nascosti e aggiuntivi di Amazon EKS
- Esempi di prezzi di Amazon EKS
- 6 modi per ridurre e ottimizzare i costi di Amazon EKS
I componenti di prezzo di AWS EKS
Esaminiamo i principali componenti di costo dei cluster Amazon EKS.
Prezzi dei cluster Amazon EKS
Amazon EKS applica una tariffa oraria per ogni cluster EKS. Il prezzo dipende dal livello di supporto della versione di Kubernetes utilizzata dal cluster:
- I cluster che eseguono una versione di Kubernetes con supporto standard costano $0.10 per cluster all'ora.
- Una versione di Kubernetes rimane in supporto standard per i primi 14 mesi dal suo rilascio su Amazon EKS.
- Al termine del supporto standard, la versione entra in supporto esteso per i successivi 12 mesi.
- Il supporto esteso costa $0.60 per cluster all'ora, ovvero la tariffa oraria standard di $0.10 più $0.50 aggiuntivi per cluster all'ora.
Questo prezzo riguarda il cluster EKS in sé. Le risorse AWS utilizzate dai workloads, come istanze EC2, volumi EBS, indirizzi IPv4 pubblici o compute Fargate, vengono fatturate separatamente.
Prezzi di Amazon EKS Provisioned Control Plane
Amazon EKS Provisioned Control Plane consente di riservare una quantità definita di capacità del control plane per un cluster. Questa opzione è pensata per workloads che richiedono prestazioni stabili del control plane, tempi di risposta più rapidi ai picchi di traffico o supporto per operazioni Kubernetes su larga scala.
Il prezzo si basa sul tier di scalabilità del control plane selezionato. L'addebito è orario e si somma alla tariffa standard del cluster EKS. Non sono previsti costi anticipati né impegni a lungo termine:
- Il tier XL costa $1.65 per cluster all'ora.
- Il tier 2XL costa $3.40 per cluster all'ora.
- Il tier 4XL costa $6.90 per cluster all'ora.
- Il tier 8XL costa $13.90 per cluster all'ora.
È possibile passare da un tier all'altro o tornare al control plane standard. Per i tier superiori a 8XL, AWS richiede di contattare il proprio account team per conoscere i prezzi.
Amazon EKS Auto Mode
Il prezzo di Amazon EKS Auto Mode si applica ai cluster in cui EKS Auto Mode è abilitato. L'addebito si basa sul tipo e sulla durata delle istanze Amazon EC2 avviate e gestite da EKS Auto Mode. Questa tariffa è separata dal prezzo delle istanze EC2: si paga il normale costo EC2 per le istanze sottostanti, mentre EKS Auto Mode aggiunge un proprio addebito di gestione.
EKS Auto Mode viene fatturato al secondo, con un minimo di un minuto. L'addebito è indipendente dall'opzione di acquisto EC2 e si applica quindi sia alle istanze On-Demand sia a Reserved Instances, Compute Savings Plans o istanze Spot. Le organizzazioni che prevedono di utilizzare EKS Auto Mode per più di 150 nodi devono contattare il proprio account team AWS per informazioni sui prezzi.
Prezzi delle Amazon EKS Capabilities
Il prezzo delle Amazon EKS Capabilities si applica quando specifiche capability vengono abilitate su un cluster EKS. Il prezzo ha due componenti orarie: un addebito base per ogni capability abilitata e un addebito d'uso basato sul numero di risorse gestite da quella capability:
- Per Argo CD nella regione US East (Ohio), l'addebito base è di $0.02771 per ora di capability Argo CD. L'addebito d'uso è di $0.00136 per ora di applicazione Argo CD. Ogni applicazione viene conteggiata per deployment su cluster di destinazione: un'applicazione distribuita su cinque cluster conta come cinque applicazioni.
- Per AWS Controllers for Kubernetes (ACK), l'addebito base è di $0.004482 per ora di capability ACK. L'addebito d'uso è di $0.000045 per ora di risorsa ACK.
- Per Kubernetes Resource Orchestrator (KRO), l'addebito base è di $0.004482 per ora di capability KRO. L'addebito d'uso è di $0.000045 per ora di istanza RGD KRO.
- Tutti gli addebiti relativi alle EKS capabilities vengono fatturati su base oraria. Non sono previsti costi anticipati né impegni minimi.
Prezzi di Amazon EKS Hybrid Nodes
Amazon EKS Hybrid Nodes consente di collegare infrastrutture on-premises o edge ai cluster Amazon EKS. In questo modo i workloads Kubernetes possono utilizzare infrastrutture esterne ad AWS mantenendo la gestione dei cluster in Amazon EKS.
Il prezzo si basa sulle vCPU-ora segnalate a Kubernetes:
- La fatturazione inizia quando un nodo ibrido entra a far parte del cluster e termina quando il nodo viene rimosso.
- Negli ambienti bare metal con hyperthreading abilitato, ogni core CPU fisico segnala due vCPU a Kubernetes e la fatturazione utilizza il numero di vCPU segnalato.
Il prezzo di Hybrid Nodes è a scaglioni, in base all'utilizzo mensile aggregato di vCPU-ora nella stessa regione AWS:
- Le prime 576,000 vCPU-ora mensili costano $0.020 per vCPU-ora.
- Le successive 576,000 costano $0.014 per vCPU-ora.
- Le successive 4,608,000 vCPU-ora mensili costano $0.010 per vCPU-ora.
- Le successive 5,760,000 costano $0.008 per vCPU-ora.
- L'utilizzo oltre le 11,520,000 vCPU-ora mensili costa $0.006 per vCPU-ora.
Se si utilizza la fatturazione consolidata tramite AWS Organizations, questi scaglioni si applicano a tutti gli account dell'organizzazione per la stessa regione. Chi prevede di eseguire nodi ibridi su macchine con più di 32 vCPU per macchina deve contattare il proprio account team AWS.
Prezzi di EKS Anywhere
Amazon EKS Anywhere è un software open source che esegue cluster Kubernetes su hardware in un data center o in un ambiente edge. Il software in sé è disponibile come open source, ma AWS vende Enterprise Subscription per il supporto e funzionalità aggiuntive:
- Una Amazon EKS Anywhere Enterprise Subscription fornisce supporto per i cluster EKS Anywhere con licenza. Dà inoltre accesso agli EKS Anywhere Curated Packages, che aggiungono funzioni come load balancing, osservabilità e auto scaling.
- Prima di acquistare una EKS Anywhere Enterprise Subscription è necessario disporre di AWS Enterprise Support o AWS Enterprise On-Ramp Support.
- Le subscription possono essere acquistate tramite console Amazon EKS, API o AWS CLI.
- Il prezzo è fisso per cluster e non dipende dalle dimensioni del cluster. Un contratto di un anno costa $24,000 per cluster, fatturati a $2,000 al mese. Un contratto di tre anni costa $18,000 per cluster all'anno, fatturati a $1,500 al mese.
- È possibile includere una o più licenze cluster EKS Anywhere in un singolo acquisto di subscription.
- Le subscription possono essere configurate per il rinnovo automatico e possono essere annullate senza costi entro i primi sette giorni.
Costi nascosti e aggiuntivi di Amazon EKS
Oltre ai componenti di base, ecco alcuni costi aggiuntivi legati ai cluster EKS di cui potrebbe non essere a conoscenza.
Costi di storage
L'esecuzione di workloads su Amazon EKS richiede spesso storage persistente, che comporta costi aggiuntivi. Questi costi derivano in genere dall'uso di volumi Amazon EBS, Amazon EFS (Elastic File System) o bucket S3 per lo storage a oggetti. Il prezzo di questi servizi di storage si basa sulla quantità di storage allocata, sul tipo di storage (ad esempio SSD o HDD) e sui requisiti di IOPS. Se i workloads richiedono storage ad alte prestazioni o grandi capacità, i costi di storage possono superare la tariffa base del cluster EKS.
I costi di storage includono anche gli addebiti per backup, snapshot e trasferimento dati. Ad esempio, la creazione regolare di snapshot EBS a fini di disaster recovery o compliance può generare addebiti mensili aggiuntivi. Le organizzazioni dovrebbero monitorare l'utilizzo dello storage, eliminare i volumi inutilizzati e applicare il right-sizing alle classi di storage per evitare spese superflue. Comprendere l'intera portata dei costi di storage aiuta a prevenire sforamenti di budget negli ambienti EKS.
Costi di trasferimento dati
I costi di trasferimento dati in Amazon EKS vengono spesso trascurati, ma possono incidere sulla fattura AWS complessiva. AWS addebita i dati trasferiti dai cluster EKS verso internet, tra Availability Zone e, in alcuni casi, tra servizi AWS in regioni diverse. Per le applicazioni con traffico in uscita elevato o comunicazione tra zone, queste tariffe possono accumularsi e diventare una parte significativa dei costi totali.
Conviene progettare i workloads EKS in modo da ridurre al minimo i trasferimenti di dati non necessari: ad esempio, mantenere il traffico all'interno della stessa Availability Zone quando possibile, oppure utilizzare AWS PrivateLink per la comunicazione tra servizi. Esaminare regolarmente i pattern di trasferimento dati e adeguare la topologia di rete aiuta a tenere sotto controllo queste spese nei deployment EKS.
Costi dei NAT Gateway
I cluster Amazon EKS che necessitano di accesso a internet da subnet private utilizzano in genere NAT Gateway. AWS addebita sia l'utilizzo orario di ciascun NAT Gateway sia la quantità di dati elaborati attraverso di essi. In ambienti ad alto traffico o in cluster con più subnet private, gli addebiti dei NAT Gateway possono crescere rapidamente.
Per ridurre i costi dei NAT Gateway, si può valutare di consolidare il traffico su un numero minore di gateway o di utilizzare istanze NAT per requisiti di throughput inferiori. È utile monitorare l'utilizzo dei NAT Gateway ed esaminare l'architettura di rete per individuare opportunità di risparmio. Poiché gli addebiti dei NAT Gateway non sono inclusi nel prezzo del control plane o dei nodi EKS, vanno considerati nel calcolo del costo totale di proprietà di EKS.
Logging e monitoraggio con CloudWatch
Amazon CloudWatch viene comunemente utilizzato per il logging e il monitoraggio dei cluster EKS, ma i suoi costi sono separati dai prezzi di EKS. Gli addebiti di CloudWatch si basano sul volume di log acquisiti, sulle metriche archiviate e sulle dashboard create. Un logging ad alta frequenza, log applicativi molto dettagliati o numerose metriche personalizzate possono far aumentare i costi, soprattutto in ambienti EKS grandi o dinamici.
Le organizzazioni dovrebbero implementare policy di retention dei log, filtrare i log superflui e aggregare le metriche per contenere le spese di CloudWatch. Anche il campionamento dei log o le soluzioni di logging di terze parti possono ridurre i costi. È buona norma esaminare regolarmente l'utilizzo di CloudWatch e ottimizzare la raccolta di log e metriche per evitare addebiti imprevisti, mantenendo al tempo stesso un'osservabilità adeguata per i workloads EKS.
Esempi di prezzi di Amazon EKS
Esempio 1: prezzo del cluster EKS con supporto standard ed esteso
Un cluster EKS esegue la stessa versione di Kubernetes per 26 mesi senza aggiornamenti del control plane. Per i primi 14 mesi la versione è in supporto standard, al costo di $0.10 per cluster all'ora. Successivamente entra in supporto esteso per 12 mesi a $0.60 per cluster all'ora.
Per vedere concretamente la differenza di costo: durante i 14 mesi di supporto standard, il cluster costa circa $1,022 in tariffe cluster totali (14 × 730 ore × $0.10). Durante i 12 mesi di supporto esteso, la cifra sale a $5,256 (12 × 730 ore × $0.60), oltre cinque volte tanto per due mesi in meno. Facendo la media sull'intero periodo di 26 mesi, la tariffa effettiva è di $0.33 per cluster all'ora.
Esempio 2: prezzi di EKS Hybrid Nodes per più business unit
Tre business unit utilizzano EKS Hybrid Nodes, ciascuna su un cluster EKS dedicato con supporto standard della versione di Kubernetes, con un addebito mensile per cluster di $73 (730 ore × $0.10).
La Business Unit 1 esegue 8 nodi da 8 vCPU ciascuno, generando 46,720 vCPU-ora e un addebito per i nodi di $934.40. La Business Unit 2 esegue 4 nodi da 16 vCPU ciascuno, generando 46,720 vCPU-ora e un addebito per i nodi di $934.40. La Business Unit 3 esegue 6 nodi da 4 vCPU ciascuno, generando 17,520 vCPU-ora e un addebito per i nodi di $350.40.
Complessivamente, le tre unità consumano 110,960 vCPU-ora nel mese. Poiché il valore è ben al di sotto del limite del primo scaglione di 576,000 vCPU-ora mensili, tutto l'utilizzo viene fatturato a $0.02 per vCPU-ora. Il totale mensile della fattura EKS è di $2,438.20, composto da $219 di addebiti per i cluster e $2,219.20 di addebiti per i nodi.
Esempio 3: esempio di prezzo di Amazon EKS Auto Mode
Un'applicazione containerizzata viene eseguita su Amazon EKS Auto Mode nella regione US West (Oregon). L'applicazione ha pod frontend, pod backend e pod di elaborazione batch. EKS Auto Mode seleziona un mix di istanze EC2 per soddisfare questi requisiti di workload.
Le istanze selezionate sono c6a.2xlarge, c6a.4xlarge, m5a.2xlarge e m5a.xlarge. Il loro costo EC2 combinato è di $1.434 all'ora. EKS Auto Mode aggiunge una tariffa di gestione separata di $0.17208 all'ora per queste istanze.
Su base mensile, ciò equivale a $1,046.82 di costi per le istanze EC2 e $125.62 di tariffe EKS Auto Mode. Questo esempio mostra che il prezzo di EKS Auto Mode si aggiunge al costo EC2 sottostante, invece di sostituirlo.
6 modi per ridurre e ottimizzare i costi di Amazon EKS
1. Applicare il right-sizing a worker node e richieste dei pod
Worker node sovradimensionati e richieste di risorse dei pod sovrastimate sono fonti comuni di sprechi nella spesa EKS. Kubernetes effettua lo scheduling dei pod in base a CPU e memoria richieste, non all'utilizzo effettivo. Se le richieste sono impostate su valori troppo alti, i cluster possono scalare inutilmente, lasciando inutilizzate ampie porzioni di capacità dei nodi pur continuando a generare costi EC2.
I team dovrebbero analizzare regolarmente il consumo effettivo di risorse e adeguare di conseguenza richieste e limiti. Strumenti come Kubernetes metrics server, Prometheus, Vertical Pod Autoscaler (VPA), KEDA e Goldilocks aiutano a individuare allocazioni inefficienti. Anche l'uso di tipi di istanza più piccoli, di gruppi di istanze miste o di istanze basate su Graviton può migliorare l'efficienza dei costi.
L'autoscaling del cluster dovrebbe essere configurato in modo da rimuovere automaticamente i nodi inutilizzati. La combinazione di un dimensionamento accurato dei pod e dell'autoscaling riduce l'infrastruttura inattiva e migliora la densità dei workloads nel cluster.
2. Usare istanze Spot per i workloads tolleranti ai guasti
Le istanze Spot di Amazon EC2 possono ridurre i costi di compute di EKS perché sfruttano capacità AWS inutilizzata a prezzi scontati. Il prezzo Spot è spesso inferiore del 70–90% rispetto al prezzo On-Demand standard, il che le rende adatte ai workloads in grado di tollerare interruzioni.
Applicazioni stateless, job batch, pipeline CI/CD, worker in background e attività di elaborazione dati sono ottimi candidati per l'uso di Spot. I node group Kubernetes possono combinare istanze Spot e On-Demand, così i workloads critici restano stabili mentre quelli tolleranti ai guasti utilizzano capacità a costo inferiore.
Per migliorare l'affidabilità, conviene utilizzare più tipi di istanza e più Availability Zone nei node group Spot. Funzionalità Kubernetes come i Pod Disruption Budget e il Cluster Autoscaler aiutano i workloads a riprendersi automaticamente in caso di interruzioni Spot.
3. Ottimizzare load balancer e ingress
Ogni service Kubernetes di tipo LoadBalancer in EKS esegue in genere il provisioning di un load balancer AWS dedicato. In ambienti di grandi dimensioni, load balancer superflui o duplicati possono generare costi mensili considerevoli, soprattutto quando si usano Application Load Balancer o Network Load Balancer.
L'uso di un ingress controller centralizzato consente a più applicazioni di condividere un unico load balancer invece di crearne uno per ogni service. L'AWS Load Balancer Controller supporta l'instradamento di più applicazioni attraverso load balancer condivisi con regole di routing basate su host o su percorso.
È opportuno eliminare i load balancer inutilizzati ed esaminare regolarmente le risorse ingress inattive. I servizi solo interni dovrebbero evitare load balancer esposti a internet, salvo quando l'accesso esterno è necessario. Ottimizzare l'architettura di ingress riduce sia gli addebiti dei load balancer sia i relativi costi di trasferimento dati.
4. Individuare risorse inattive e sottoutilizzate
Le risorse Kubernetes inutilizzate spesso continuano a generare addebiti AWS anche quando le applicazioni non sono più attive. Nodi EC2 inattivi, volumi EBS non collegati, load balancer orfani, Elastic IP inutilizzati e namespace inattivi sono esempi comuni di spreco negli ambienti EKS.
Revisioni regolari di costi e utilizzo aiutano a individuare le risorse che possono essere eliminate o consolidate. AWS Cost Explorer, AWS Compute Optimizer, Kubecost e gli strumenti di monitoraggio Kubernetes possono tracciare l'uso inefficiente delle risorse nei cluster.
Automatizzare i processi di pulizia migliora il controllo dei costi. Le organizzazioni possono utilizzare policy di ciclo di vita, spegnimenti programmati per gli ambienti non di produzione e regole di scadenza dei namespace per ridurre le spese superflue. Il monitoraggio continuo è importante perché gli ambienti Kubernetes cambiano di frequente, man mano che i workloads scalano e i team distribuiscono nuovi servizi.
5. Aggiornare le versioni di Kubernetes prima del supporto esteso
Amazon EKS aumenta il prezzo del cluster quando una versione di Kubernetes passa dal supporto standard al supporto esteso. La tariffa oraria del cluster sale da $0.10 a $0.60 per cluster all'ora, il che può far crescere i costi su più cluster.
Aggiornamenti regolari di Kubernetes aiutano le organizzazioni a evitare questi addebiti aggiuntivi, migliorando al contempo sicurezza, stabilità e disponibilità di funzionalità. Definire un calendario di aggiornamento prevedibile riduce il rischio che i cluster restino a lungo su versioni non supportate.
Conviene testare gli aggiornamenti in ambienti di staging prima del rollout in produzione per ridurre il rischio operativo. I team dovrebbero inoltre monitorare il calendario di rilascio di Amazon EKS e pianificare gli aggiornamenti con sufficiente anticipo, per evitare migrazioni affrettate a ridosso delle scadenze del supporto.
6. Usare Karpenter per un provisioning dei nodi più intelligente
Karpenter può contribuire a ridurre i costi di Amazon EKS effettuando il provisioning della capacità di calcolo in base ai requisiti effettivi dei pod, invece di affidarsi solo a node group predefiniti. Valuta i pod in attesa e avvia istanze EC2 correttamente dimensionate in base alle esigenze dei workloads, migliorando il bin packing, riducendo la capacità inattiva e accelerando lo scaling.
A differenza delle configurazioni tradizionali del Cluster Autoscaler, che dipendono fortemente dagli Auto Scaling Group, Karpenter può scegliere tra una gamma più ampia di tipi di istanza, dimensioni, Availability Zone, architetture e tipi di capacità. Questa flessibilità consente ai team di utilizzare un mix più vario di istanze On-Demand, Spot e basate su Graviton, mantenendo al tempo stesso la disponibilità delle applicazioni.
Karpenter è particolarmente utile per workloads dinamici o variabili, perché può aggiungere rapidamente capacità quando i pod non possono essere schedulati e consolidare i nodi sottoutilizzati quando la domanda cala. I team dovrebbero configurare i NodePool con requisiti di istanza appropriati, controlli di disruption, policy di consolidamento e vincoli dei workloads per bilanciare i risparmi con l'affidabilità.
Ottimizzare i costi di EKS con PerfectScale
EKS offre una piattaforma potente per eseguire workloads containerizzati, ma con questo modello di prezzo le configurazioni inefficienti delle risorse si traducono direttamente in fatture più alte. Richieste di CPU e memoria sovradimensionate fanno scalare i cluster più del necessario, mantenendo i nodi EC2 in esecuzione a basso utilizzo mentre i costi si accumulano. PerfectScale by DoiT elimina questo spreco analizzando continuamente il consumo effettivo dei workloads nei cluster EKS e applicando in autonomia il right-sizing di richieste e limiti di CPU e memoria, senza richiedere tuning manuale o tempo di engineering.
A differenza degli strumenti che si limitano a generare raccomandazioni, su cui i team raramente hanno la capacità di intervenire, PerfectScale applica le ottimizzazioni automaticamente, mantenendo guardrail che proteggono prestazioni e disponibilità. Rileva e corregge in tempo reale i rischi di resilienza come OOM kill, throttling della CPU ed eviction dei pod, così i risparmi non vanno a scapito della stabilità. Il risultato è un cluster più compatto e meglio utilizzato, che spende meno in capacità EC2 superflua mantenendo l'affidabilità richiesta dai suoi workloads.