# AWS Graviton5 e le nuove istanze EC2: perché i chip ARM nel cloud contano
Table of Contents
Il 10 giugno 2026 AWS ha reso disponibili a tutti due nuovi tipi di server virtuali nel suo cloud: le istanze EC2 chiamate M9g e M9gd. La novità sotto il cofano è il processore che le muove, Graviton5, presentato in anteprima a fine 2025 e ora arrivato alla disponibilità generale. È l’occasione per spiegare, senza tecnicismi inutili, una cosa che ormai riguarda chiunque affitti server nel cloud: perché i processori ARM stanno prendendo piede e cosa conviene controllare prima di spostarci sopra i propri programmi.
Cosa significano “ARM” e “istanza”, in breve
Un’istanza EC2 è semplicemente un server virtuale che si affitta a ore: gli si dà una potenza di calcolo e della memoria, ci si installa sopra Linux e ci girano i propri servizi. Il “motore” di quel server è il processore, cioè il chip che esegue i calcoli.
Per anni i processori dei server hanno seguito quasi tutti la stessa impostazione di fondo, quella dei chip Intel e AMD, nota come x86. ARM è un modo diverso di costruire i processori: è la stessa famiglia di architettura che si trova negli smartphone e nei computer portatili moderni, nata con un’attenzione forte al consumo di energia. La differenza tecnica non interessa all’utente finale; interessa la conseguenza pratica: a parità di lavoro svolto, un chip ARM tende a consumare meno corrente e a costare meno da far girare.
Graviton è la linea di processori ARM che AWS progetta per conto proprio, invece di comprarli da altri. Non è una novità assoluta: esiste da alcuni anni ed è arrivata alla quinta generazione. Graviton5 è appunto l’ultimo passo.
Perché contano i chip ARM nel cloud
Il punto non è il tifo per una tecnologia o l’altra. Il punto è il conto della spesa e il conto dei consumi.
Nel cloud si paga il tempo di calcolo. Se lo stesso servizio gira su un chip che rende di più a parità di corrente assorbita, il fornitore può proporre quel calcolo a un prezzo inferiore. Storicamente le istanze ARM di AWS sono state offerte a listino più basso rispetto alle equivalenti x86, ed è questa combinazione - prestazioni per euro speso e consumi contenuti - la ragione per cui tante aziende hanno cominciato a guardarle.
C’è poi il lato ambientale ed economico dei data center. Un processore che fa lo stesso lavoro con meno energia significa meno calore da smaltire e meno corrente in bolletta: due voci pesanti per chi gestisce migliaia di server.
Cosa cambia con Graviton5
AWS descrive Graviton5 come il processore più potente ed efficiente che abbia mai costruito. I numeri dichiarati, da leggere sempre con il “fino a” davanti perché sono valori di punta e non medie garantite, sono questi:
- fino al 25% di prestazioni di calcolo in più rispetto alla generazione precedente, Graviton4;
- guardando a carichi specifici, fino al 35% più veloce per le applicazioni web, fino al 35% per l’inferenza dei modelli di intelligenza artificiale (cioè l’uso di un modello già addestrato) e fino al 30% per i database;
- 192 core per processore (i core sono le unità di calcolo indipendenti: più core significano più cose in parallelo);
- cinque volte più cache L3 rispetto alla generazione precedente. La cache è una piccola memoria molto veloce accanto al processore: più è ampia, meno il chip deve fermarsi ad aspettare i dati;
- fino al 33% di latenza in meno tra i core, cioè i core si scambiano informazioni più in fretta;
- memoria DDR5-8800, tra le più rapide disponibili oggi nel cloud.
Sono cifre fornite dal produttore. Restano un’indicazione utile della direzione, ma il valore reale dipende sempre dal carico specifico.
Le due istanze: M9g e M9gd
Le nuove istanze arrivano in due varianti che condividono lo stesso processore.
M9g è la versione generica, adatta alla maggior parte dei servizi: siti, applicazioni web, backend, database di dimensioni normali. Le taglie vanno da 1 vCPU con 4 GiB di memoria fino a 192 vCPU con 768 GiB. Un vCPU è la fetta di processore assegnata all’istanza; qui il rapporto è di un vCPU ogni quattro GiB di memoria.
M9gd aggiunge dello spazio su disco NVMe locale, cioè memoria a stato solido molto veloce fisicamente collegata al server, fino a 11,4 TB. Serve a chi ha bisogno di leggere e scrivere dati in locale a grande velocità - per esempio certe basi di dati o sistemi di cache - senza passare da un disco di rete. AWS indica per questa variante anche un aumento delle operazioni di lettura e scrittura al secondo rispetto al passato.
Le istanze sono acquistabili nei modi consueti di AWS (a consumo, con i piani di risparmio, in modalità Spot per i carichi interrompibili, e nelle forme dedicate) e, al lancio, sono disponibili in alcune regioni: Stati Uniti (Virginia del Nord, Ohio, Oregon) ed Europa (Francoforte). La copertura è quindi ancora parziale, come normale per una novità appena uscita.
Sul fronte sicurezza, AWS le costruisce sulla sesta generazione del suo sistema Nitro e introduce un componente chiamato Nitro Isolation Engine, che rafforza l’isolamento tra le macchine virtuali che condividono lo stesso hardware fisico.
Cosa valutare prima di migrarci i propri carichi Linux
Passare da x86 ad ARM non è un semplice cambio di taglia. È un cambio di architettura del processore, e questo ha conseguenze concrete. Ecco i punti da controllare, in ordine di importanza.
Il software deve esistere in versione ARM. Un programma compilato per x86 non gira su ARM così com’è. La buona notizia è che le distribuzioni Linux più diffuse (Debian, Ubuntu, Amazon Linux, RHEL e derivate) offrono da tempo versioni per ARM a 64 bit, indicata come arm64 o aarch64. La maggior parte dei linguaggi interpretati - PHP, Python, Node.js, Java - funziona senza riscrivere nulla.
Attenzione alle dipendenze compilate. Il problema si nasconde nei componenti “nativi”: estensioni di un linguaggio, librerie di sistema, software proprietario fornito come binario già pronto. Se un pezzo esiste solo per x86, va sostituito, ricompilato o accantonato. Vale la pena censire in anticipo cosa usa il proprio stack, un lavoro più veloce se l’infrastruttura è già descritta come codice.
Le immagini dei container vanno controllate. Chi usa Docker deve verificare che le immagini siano “multi-architettura”, cioè disponibili anche per linux/arm64. Molte immagini ufficiali lo sono già; quelle costruite in casa vanno ricostruite per ARM.
Provare con i propri dati, non con i numeri del listino. Le percentuali dichiarate sono valori di punta. L’unico test che conta è misurare il proprio carico reale su una piccola istanza ARM e confrontarlo con quella x86 che si usa oggi, guardando sia le prestazioni sia il costo effettivo nella propria regione.
Verificare il prezzo caso per caso. Il vantaggio economico di ARM è storicamente reale, ma non è una legge fissa: dipende dalla regione, dalla taglia e dalla forma d’acquisto. Va confermato sul preventivo, non dato per scontato.
In pratica, per molti servizi Linux moderni la migrazione ad ARM è oggi meno faticosa di quanto si tema, e il risparmio può essere concreto. Per stack più vecchi o pieni di componenti proprietari, invece, conviene procedere con calma: prima l’inventario del software, poi una prova affiancata, e solo dopo la decisione. Graviton5 rende l’opzione ARM più interessante, ma la scelta giusta resta quella misurata sul proprio caso.
