Google Cloud Next '26: le novità essenziali per la tua infrastruttura

Sei un'azienda retail con un sistema gestionale (ERP) perfettamente stabile e stai valutando di aggiungere un agente AI che aggiorni i prezzi sul tuo sito in tempo reale?

L'agente controlla il magazzino, calcola gli sconti, suggerisce i prodotti correlati.

In teoria, un'ora di lavoro automatizzata, in pratica, ogni volta che un utente effettua una ricerca, il sistema mette in moto decine di operazioni in parallelo, il database va in affanno e il sito rallenta.

Non è un problema di codice, ma di architettura.

Google ha introdotto il concetto di fluid compute, un'infrastruttura intelligente che sposta la potenza di calcolo in tempo reale dove serve di più, unendo i programmi tradizionali alle nuove funzioni AI.

Google Cloud Next '26 - l’evento annuale che Google tiene a Las Vegas - ha messo al centro la scalabilità e l'efficienza dei sistemi. Ecco le novità infrastrutturali che possono fare la differenza rispetto a costi e prestazioni per aziende come la tua già da oggi.

I nuovi processori Axion: quando conviene cambiare i tuoi server

Torniamo all'esempio del retailer.

Il problema non è che il sito sia mal sviluppato, è che i server su cui gira sono stati progettati per un mondo in cui le operazioni arrivano in sequenza, non tutte insieme.

I processori x86 tradizionali gestiscono i picchi di carico “sdoppiando” ogni core fisico in due canali virtuali, una tecnica chiamata Simultaneous Multithreading. Funziona bene fino a un certo punto, dopodiché i due canali si contendono le stesse risorse e le prestazioni diventano imprevedibili proprio quando servirebbero stabili.

I nuovi processori Google Axion eliminano questo compromesso alla radice.

Ogni unità di calcolo corrisponde a un core fisico reale: nessuna condivisione, nessuna variabile nascosta sotto carico.

Il risultato è un comportamento del sistema molto più prevedibile, che si traduce in latenza stabile anche nei momenti di punta e in una bolletta cloud più contenuta.

Google ha sviluppato due famiglie distinte di processori, con filosofie opposte.

Google Axion N4A: abbatti il costo delle applicazioni distribuite

Le istanze N4A sono la risposta per chi gestisce molti server in parallelo e vuole ridurre il costo complessivo senza sacrificare affidabilità.

Rispetto ai server x86 di generazione precedente, offrono fino al 105% di miglioramento nel rapporto prezzo/prestazioni e un consumo energetico inferiore fino all'80%.

Considera il caso di un'azienda manifatturiera con un sistema ERP distribuito su trenta microservizi, ognuno su una macchina separata. Ogni mese quella flotta pesa decine di migliaia di euro.

Migrando su istanze N4A, spesso senza modificare una riga di codice applicativo, quella stessa azienda può aspettarsi risparmi reali sulla bolletta mensile, sia rispetto all'equivalente x86 che rispetto alle più costose C4A. Il guadagno non viene dalla velocità del singolo server, ma dall'efficienza complessiva della flotta.

Le N4A danno il meglio nelle architetture che scalano orizzontalmente: server web, microservizi, container su Google Kubernetes Engine (GKE), applicazioni Java enterprise, pipeline di compilazione e job batch. Sono anche la scelta giusta per eseguire modelli AI leggeri già addestrati direttamente su CPU, senza pagare GPU dedicate.

Google Axion C4A: zero compromessi su latenza e velocità

Se le N4A sono la scelta dell'efficienza, le C4A sono la scelta della potenza. Sono progettate per situazioni in cui ogni millisecondo ha un costo reale e il picco di carico deve essere assorbito senza esitazioni.

Pensa a una piattaforma di pagamenti online che processa transazioni in tempo reale. Il database deve rispondere in meno di dieci millisecondi, anche con migliaia di richieste simultanee. Le C4A raggiungono i 100 Gbps di banda di rete e possono collegare dischi SSD fisici locali (Titanium SSD) direttamente al server, eliminando il salto di latenza che normalmente si paga passando per lo storage di rete. Nei calcoli a singolo thread, nella compressione dati e nella crittografia AES si dimostrano fino al 100% più veloci delle N4A.

I contesti in cui fanno la differenza sono database transazionali ad alto traffico come PostgreSQL o Cloud SQL, infrastrutture di caching come Redis o Memcached, server di gioco online e sistemi AdTech, dove la latenza variabile si traduce direttamente in mancato fatturato.

La scelta tra le due famiglie si riduce a una domanda sola: il tuo problema principale è il costo della flotta o la velocità del singolo processo? Nel primo caso N4A, nel secondo C4A.

Chiedici come Google Cloud Platform può supportare ed evolvere l'infrastruttura della tua azienda.

C4A.metal: quando anche il miglior server virtuale non basta

C'è una categoria di carichi di lavoro per cui qualsiasi strato di virtualizzazione è già troppo: simulazioni industriali di fluidodinamica, rendering 3D in produzione, test continui di firmware embedded, sviluppo di applicazioni che devono girare su hardware specifico.

In questi contesti, la virtualizzazione introduce una variabile che non riesci a controllare e che nei momenti peggiori diventa un collo di bottiglia impossibile da diagnosticare.

Le nuove istanze C4A.metal risolvono questo problema mettendo i processori Axion direttamente a disposizione dell'applicazione, senza filtri software intermedi.

L'accesso bare metal (cioè alla macchina fisica pura) era già disponibile su altre famiglie Google Cloud, ma portarlo sui nuovi Axion significa combinare la potenza del chip di ultima generazione con la prevedibilità assoluta dell'hardware dedicato.

Per le aziende che hanno sempre tenuto i carichi più pesanti su server fisici in sede perché il cloud "non reggeva", questa opzione apre per la prima volta una strada credibile verso la nuvola senza dover accettare compromessi prestazionali.

GKE Agent Sandbox: come portare gli agenti AI in produzione su sistemi che già funzionano

Un agente AI non è un chatbot. Un chatbot risponde a domande, un agente esegue azioni, accede a database, chiama API esterne, genera e lancia codice in modo autonomo. Questo è il suo valore, ma è anche il rischio che molte aziende sottovalutano fino al primo incidente.

Per restare sull’esempio del retailer, l'agente AI deve aggiornare i prezzi in base alla disponibilità di magazzino, tutto funziona correttamente per settimane.

Poi arriva un input anomalo, un prodotto con una codifica insolita o un valore fuori scala, e l'agente genera un comando errato.

Se quel comando viene eseguito direttamente sui sistemi aziendali, il risultato può essere un aggiornamento massiccio di prezzi sbagliati, un blocco del database o, nel caso peggiore, una falla di sicurezza aperta verso l'esterno.

GKE Agent Sandbox è quel layer. Crea un ambiente isolato in cui l'agente esegue i suoi comandi senza avere accesso reale ai sistemi aziendali. Se qualcosa va storto, l'errore rimane confinato, la sandbox si distrugge in pochi secondi e il sistema principale non ne sa nulla. Quando invece tutto funziona correttamente, il risultato viene propagato ai sistemi reali in modo controllato e verificabile.

Dal punto di vista dei costi, la sandbox sfrutta le istanze Axion N4A, che la rendono strutturalmente più veloce del 30% rispetto alle soluzioni equivalenti di AWS e Azure, con un impatto contenuto sulla bolletta. Per un'azienda che sta portando il primo agente in produzione è la differenza tra un lancio controllato e una crisi da gestire il giorno dopo.

Conosci Gemini Enterprise? È la piattaforma agentica di Google che connette sistemi eterogenei e permette di costruire agenti AI che producono sintesi, svolgono azioni, forniscono previsioni e segnali di alert proattivi.

Ne abbiamo parlato nel nostro webinar “Gemini Enterprise come usare gli agenti AI sui dati reali aziendali”, ma se hai pochi minuti puoi leggere la nostra breve guida qui!

Flexible CUD 2026: finalmente gli sconti seguono il tuo business

I Committed Use Discount (CUD) sono il meccanismo con cui Google premia le aziende che si impegnano a usare i suoi servizi per un periodo definito, tipicamente uno o tre anni. La logica è semplice: tu garantisci prevedibilità, Google riduce la tariffa.

Fino ad oggi, però, questa flessibilità aveva un limite pratico: gli sconti si applicavano a un insieme ristretto di server standard, e spostarsi da una risorsa all'altra, o da una regione all'altra, significava spesso perdere le agevolazioni già attive.

Con gli aggiornamenti annunciati a Cloud Next '26, la copertura si allarga in modo significativo. I CUD si applicano ora alle istanze ottimizzate per memoria dalla serie M1 alla M4, ai sistemi di calcolo intensivo H3 e H4D, e a Cloud Run, la piattaforma che permette di eseguire applicazioni containerizzate senza gestire l'infrastruttura sottostante.

Cosa cambia in concreto? Un'azienda che oggi paga Cloud Run a consumo per i suoi microservizi può impegnarsi su un volume mensile, ottenere uno sconto strutturale e spostare il budget risparmiato verso altri servizi senza perdere le agevolazioni già attive.

Per un CFO o un responsabile IT significa trasformare una voce di spesa variabile e difficile da prevedere in un costo pianificabile con più margine per investire dove serve davvero.

Vuoi ottimizzare i costi infrastrutturali di Google Cloud? Leggi la nostra guida.

Cross-Cloud Infrastructure: i tuoi dati dove servono, senza migrazioni forzate

Nella maggior parte delle aziende i dati non vivono in un posto solo: il CRM è su Salesforce, i dati storici di vendita stanno su AWS S3, i sistemi gestionali girano su Azure o su server fisici in sede.

Quando vuoi usare l'AI di Google Cloud per analizzare tutto questo insieme, ti scontri con un problema concreto, spostare grandi volumi di dati tra cloud diversi è lento, complicato e costoso, sia in termini di ore tecniche che di tariffe di trasferimento.

Gli annunci di Cloud Next '26 affrontano questo problema da due direzioni.

Da un lato, Google ha potenziato i collegamenti diretti e sicuri con AWS e Azure, riducendo latenza e costi di trasferimento tra reti. Dall'altro, ha introdotto un cross-cloud Lakehouse nell'Agentic Data Cloud: un'architettura che permette ai tuoi agenti AI di interrogare i dati dove si trovano, senza doverli prima copiare su Google Cloud.

Il risultato pratico è che un agente può accedere in modo nativo a dati su AWS, elaborarli con i modelli Google e scrivere i risultati dove serve, senza che il tuo team debba costruire e mantenere pipeline di sincronizzazione tra ambienti diversi. Per chi ha costruito un'infrastruttura multi-cloud nel tempo questa è la strada per iniziare a sfruttare l'AI senza dover rimettere in discussione l'architettura esistente.

Cosa fare adesso: quattro verifiche che puoi fare già questa settimana

Le novità di Cloud Next '26 non richiedono di riprogettare tutto. Richiedono di capire dove sei oggi e dove ha senso intervenire per primo.

1. La prima verifica riguarda i tuoi server. Se stai usando macchine x86 per applicazioni web, microservizi o software Java, un'analisi comparativa sulle istanze Axion N4A può rivelare risparmi reali sulla bolletta mensile. È il tipo di intervento con il ROI più immediato e il rischio più basso.
2. La seconda riguarda i tuoi agenti AI. Se hai un progetto di intelligenza artificiale in fase di lancio o già parzialmente operativo, introdurre GKE Agent Sandbox prima del go-live è molto più semplice. Pianificarlo adesso, quando l'architettura è ancora in costruzione, evita di dover tornare indietro.
3. La terza riguarda gli sconti attivi. Controlla se i servizi che stai già usando (Cloud Run in particolare) rientrano ora nella copertura dei Flexible CUD. Se hai impegni in scadenza nei prossimi mesi, è il momento giusto per rinegoziare prima che scadano.
4. La quarta riguarda il tuo ecosistema multi-cloud. Se hai dati rilevanti per l'AI distribuiti su AWS o Azure, verifica concretamente quanto ti costa oggi trasferirli e tenerli sincronizzati. Le nuove soluzioni Cross-Cloud di Google possono ridurre quella voce di costo e aprire casi d'uso che oggi sembrano troppo complessi da implementare.

Vuoi un'analisi del tuo ecosistema Google Cloud? Prenota un meet con il nostro team, ottimizziamo insieme costi, sicurezza e prossimi passi.

Domande frequenti

Devo migrare subito a Axion, o posso aspettare?

Non è necessario farlo tutto in una volta. La strategia più efficace è identificare i carichi di lavoro con il costo più alto, tipicamente le flotte di microservizi o i server web, e testarli prima su istanze N4A. Google offre strumenti di migrazione graduali che permettono di spostare singoli servizi senza toccare il resto dell'infrastruttura. Un buon punto di partenza è un'analisi comparativa prima di qualsiasi intervento.

GKE Agent Sandbox funziona anche con agenti già in produzione?

Sì, può essere introdotta anche su ambienti esistenti. In alcuni casi richiede una revisione dell'architettura di deployment, ma è progettata per integrarsi con i cluster Kubernetes già attivi. È un intervento che conviene pianificare con un tecnico prima di farlo in autonomia, soprattutto se l'agente è già in produzione.

I Flexible CUD si applicano retroattivamente agli impegni già in corso?

No, gli impegni esistenti rimangono nelle condizioni originali fino alla scadenza. Le nuove coperture si applicano ai contratti stipulati da questo momento in poi. Se hai impegni in scadenza nei prossimi mesi, è il momento giusto per rinegoziare prima del rinnovo automatico.

Cosa si intende esattamente per Cross-Cloud Infrastructure?

È l'insieme di tecnologie che permette a Google Cloud di connettersi in modo diretto e sicuro con altri provider come AWS e Azure. La novità rispetto al passato è che non richiede di spostare i dati: gli agenti AI di Google possono interrogarli dove si trovano, riducendo latenza, costi di trasferimento e complessità tecnica.

Conviene passare a Cloud Run solo per i nuovi CUD?

Non necessariamente. Cloud Run ha senso quando vuoi eseguire applicazioni containerizzate senza gestire l'infrastruttura sottostante. Se ci sei già, o stai valutando il passaggio per motivi tecnici, il fatto che ora rientri nei CUD è un vantaggio economico concreto. Ma non è una ragione sufficiente da sola per migrare: la decisione deve partire dall'architettura, non dallo sconto.