In breve
Il 23 ottobre 2026 il CEO di Amazon Andy Jassy ha dichiarato che la capacità di AWS è esaurita per il 2026, «in gran parte esaurita» per il 2027 e che anche una buona parte del 2028 è prenotata, nonostante circa 220 miliardi di dollari di investimenti previsti per il 2026. AWS tiene ancora da parte capacità per EC2 on demand e Bedrock, ma i grandi blocchi sono già impegnati. Se il vostro prodotto avrà bisogno di GPU o di molta potenza di calcolo nei prossimi 12–24 mesi, inserite la capacità come voce fissa della vostra roadmap cloud e DevOps. Prenotate presto, usatela in modo efficiente e mantenete la possibilità di spostarvi.
Cosa ha detto Andy Jassy sulla capacità di AWS?
Jassy è intervenuto a The a16z Show, il podcast di Andreessen Horowitz, con il cofondatore Ben Horowitz e il general partner Erik Torenberg, in un episodio pubblicato venerdì 23 ottobre. Ha spiegato che AWS ha già venduto la capacità di quest’anno e che anche il 2027 è «in gran parte esaurito». AWS lascia sempre una parte di capacità per l’uso on demand e per il servizio di inferenza Bedrock o EC2, ha precisato, ma «vende in gran parte tutti i grandi blocchi». Ha aggiunto che «una buona parte del ’28 è esaurita». Reuters e The Information hanno riportato le dichiarazioni lo stesso giorno.
Tutto questo mentre Amazon investe più che mai. A luglio l’azienda ha alzato il piano di investimenti 2026 a circa 220 miliardi di dollari, anche perché la memoria è diventata più cara. Nel podcast Jassy ha detto che Amazon «potrebbe investire molto di più e non sarebbe un cattivo uso del capitale». La domanda arriva dai laboratori di IA e dalle aziende che integrano l’IA nei propri prodotti. Né Amazon né gli articoli hanno indicato clienti, regioni o tipi di chip specifici dietro le prenotazioni.
Perché la capacità cloud si sta esaurendo?
Il collo di bottiglia non sono i soldi, ma l’offerta fisica. Jassy ha indicato tre limiti: spazio nei data center, energia e memoria. Nessuno si risolve in un trimestre. I nuovi siti richiedono anni di autorizzazioni e costruzione, le connessioni alla rete elettrica scarseggiano in molte aree e la memoria ad alta larghezza di banda per gli acceleratori IA è limitata in tutto il settore. Se il più grande provider cloud si dice prenotato fino al 2028 anche con questo livello di spesa, i concorrenti sono quasi certamente sotto una pressione simile.
Per chi acquista, il dettaglio chiave è come AWS distribuisce ciò che ha. La quota maggiore va agli impegni pluriennali dei grandi clienti, soprattutto laboratori di IA e aziende che hanno prenotato per tempo. Il resto è riservato all’uso on demand e all’inferenza gestita. In pratica un team di medie dimensioni oggi può ancora avviare istanze e chiamare modelli, ma la capacità ampia o specializzata, come grandi cluster GPU per training o fine-tuning, è la più difficile da ottenere con poco preavviso, e può costare di più quando la si ottiene.
Cosa significa per i team software in Italia
Primo: la pianificazione della capacità ora fa parte della pianificazione di prodotto. Se la vostra roadmap 2027 prevede training o fine-tuning di modelli, inferenza ad alto volume o una grande migrazione, il momento per assicurarsi la potenza di calcolo è prima che il lavoro inizi, non quando il backlog ci arriva. AWS offre già strumenti a questo scopo, come le capacity reservation, i prezzi con impegno d’uso e i blocchi GPU programmati per il ML. Il rovescio della medaglia è che vi impegnate a spendere prima che la domanda sia dimostrata, quindi dimensionate le prenotazioni su previsioni difendibili. Prenotare troppo sposta solo il rischio dalla disponibilità al costo.
Secondo: i servizi gestiti diventano la scelta predefinita più sicura. Jassy ha detto che AWS tiene da parte capacità per l’inferenza tramite Bedrock ed EC2. I team che chiamano i foundation model attraverso un servizio gestito come Amazon Bedrock attingono a quel bacino e non devono procurarsi una propria flotta di GPU. Per la maggior parte dei team di prodotto è un motivo per preferire l’inferenza gestita ai cluster di modelli self-hosted, a meno che regole sui dati, costi su larga scala o controllo del modello non giustifichino chiaramente la gestione in proprio.
Terzo: l’efficienza ora incide sulla disponibilità oltre che sul costo. Quando il calcolo scarseggia, rilascia prima il team che ne ha bisogno di meno. Modelli più piccoli o distillati, caching delle risposte, batching e istanze ben dimensionate riducono la bolletta e anche la dipendenza da una capacità scarsa. Lo stesso vale per la portabilità: i carichi definiti come infrastructure-as-code e containerizzati su Kubernetes possono spostarsi su un’altra regione o un altro provider quando una è satura. Verificate in anticipo che ogni regione di ripiego rispetti i vostri obblighi GDPR e di residenza dei dati.
Come pianificare la capacità adesso?
- Prevedere 12–24 mesi di fabbisogno di calcolo. Suddiviso per carico: training, inferenza, batch, carico di base. Le attività ad alto uso di GPU vanno in cima alla coda.
- Prenotare ciò che potete giustificare. Usate capacity reservation o impegni per il carico di base prevedibile e lasciate on demand i picchi e le sperimentazioni.
- Preferire l’inferenza gestita. Dove possibile, chiamate i modelli tramite servizi gestiti invece di costruire cluster GPU propri.
- Rendere l’efficienza un criterio di rilascio. Misurate il calcolo per richiesta o per utente e usate caching, batching e modelli più piccoli prima di scalare l’hardware.
- Mantenere i carichi portabili. Usate infrastructure-as-code e container, così una carenza di capacità in una regione o in un cloud non blocca un lancio.
- Verificare la conformità delle regioni di ripiego. Accertatevi che ogni regione alternativa rispetti i requisiti di residenza dei dati e normativi (GDPR e, se applicabili, qualificazione ACN o DORA) prima che un incidente imponga lo spostamento.
- Rivedere le ipotesi di prezzo. Una capacità scarsa può significare meno sconti. Mettetelo a budget nei piani cloud 2027.
Domande frequenti
AWS ha davvero esaurito la capacità?
Non del tutto. Il 23 ottobre 2026 il CEO di Amazon Andy Jassy ha detto che la capacità AWS del 2026 è venduta, che il 2027 è «in gran parte esaurito» e che anche una buona parte del 2028 è venduta. Secondo Jassy, AWS tiene sempre da parte una quota per l’uso on demand e per l’inferenza tramite Bedrock ed EC2. A essere esauriti sono i grandi blocchi impegnati dai clienti più grandi. I team possono ancora avviare istanze e chiamare modelli, ma la capacità ampia o specializzata, soprattutto GPU, è più difficile da ottenere con poco preavviso.
Perché Amazon non costruisce semplicemente più data center?
Amazon prevede già circa 220 miliardi di dollari di investimenti nel 2026 e Jassy ha detto che potrebbe investire di più. I limiti sono fisici: i data center richiedono anni per essere costruiti, energia e connessioni alla rete scarseggiano e la memoria per l’hardware IA è carente in tutto il settore. Jassy ha indicato data center, energia e memoria come colli di bottiglia.
Come può un team software assicurarsi capacità cloud?
Prevedete il fabbisogno di calcolo con 12–24 mesi di anticipo, carico per carico, e prenotate la capacità per il carico di base prevedibile con le opzioni di prenotazione o di impegno del provider. Lasciate on demand i carichi sperimentali e irregolari. Preferite i servizi gestiti per l’inferenza, perché AWS dichiara di riservare capacità a questi. Riducete il fabbisogno con caching, batching e modelli più piccoli e mantenete i carichi portabili con infrastructure-as-code e container, così da poter cambiare regione o provider se uno è saturo.
La carenza di capacità AWS colpisce in modo diverso i team in Italia?
Gli articoli non hanno suddiviso la capacità per regione, quindi non esistono dati pubblicati per la regione di Milano. La differenza pratica per i team italiani è la conformità: se pensate di spostarvi o espandervi in un’altra regione perché la vostra è satura, quella regione deve comunque rispettare i vostri obblighi GDPR e di residenza dei dati e, per la pubblica amministrazione, i requisiti di qualificazione ACN. Verificatelo in anticipo e inserite regioni di ripiego conformi nel piano di capacità, invece di sceglierne una durante un incidente.
Fonti
The a16z Show — Il CEO di Amazon Andy Jassy sul piano IA da 220 miliardi di dollari (fonte primaria, 23 ottobre 2026)
Reuters (via U.S. News) — Capacità cloud di Amazon esaurita fino al 2027, dice il CEO Jassy (23 ottobre 2026)
The Information — AWS in gran parte esaurita fino al 2028, secondo Jassy (23 ottobre 2026)
CNBC — Amazon alza il capex 2026 a 220 miliardi di dollari per i maggiori costi della memoria (30 luglio 2026)