Alle 10 del mattino (ora orientale) del 28 novembre 2025, la spesa online negli Stati Uniti è salita verso i $12.5 milioni al minuto e si è mantenuta vicino a quel ritmo per ore. Dietro ognuna di quelle transazioni c'erano un server web, una connessione al database e una policy di autoscaling che ha tenuto il passo o meno. Per il team che gestisce quell'infrastruttura, i codici sconto contavano meno del fatto che la flotta potesse aggiungere capacità prima che le pagine di checkout andassero in timeout. Quella decisione viene presa settimane prima, nei file di configurazione che la maggior parte degli acquirenti non vede mai.
Regole di autoscaling sotto pressione prima della corsa festiva
Amazon Web Services raccomanda il target tracking come policy iniziale per la maggior parte dei carichi di lavoro. Un team sceglie una metrica, spesso l'utilizzo della CPU, e imposta un valore target. Una policy di scaling basata sul target tracking può mirare a un utilizzo medio della CPU del 50 percento. Da lì, il fornitore cloud aggiunge o rimuove istanze autonomamente per mantenere tale soglia.
La policy presenta una particolarità che coglie di sorpresa i nuovi team. Una policy di scaling basata sul target tracking presuppone di dover aumentare le risorse quando la metrica specificata supera il valore target, ma non può aumentarle quando la metrica si trova al di sotto di tale obiettivo. Ciò significa che una crescita lenta e costante del traffico viene gestita bene. Un calo improvviso in una metrica diversa, che la policy non è mai stata impostata per monitorare, non innescherà alcuna risposta.
Ecco perché la documentazione AWS tratta il target tracking come una base di partenza piuttosto che come una soluzione completa. Nella maggior parte dei casi, una policy di scaling basata sul target tracking è sufficiente per aumentare e diminuire automaticamente le risorse di un gruppo Auto Scaling. Ma la frase operativa è "nella maggior parte dei casi", non in tutti.
Warm pool, step scaling e base di capacità
Lo scaling reattivo ha un problema di ritardo intrinseco durante un picco improvviso. Un picco che arriva più velocemente del ciclo di valutazione della metrica supererà l'obiettivo prima che il target tracking risponda. Quando la policy se ne accorge, il danno ai tempi di caricamento della pagina è già iniziato.
Due strumenti colmano questa lacuna. Il primo è lo step scaling, che reagisce con salti più ampi una volta superata una soglia, utile per il traffico virale o da flash-sale piuttosto che per il lento ritmo quotidiano gestito bene dal target tracking. Il secondo è il warm pool. I warm pool mantengono istanze EC2 pre-inizializzate in stati arrestati o in esecuzione, pronte a unirsi immediatamente a un gruppo Auto Scaling durante gli eventi di scale-out. I team dovrebbero utilizzare i warm pool quando un'applicazione presenta lunghe sequenze di avvio, quando la latenza di scaling influisce direttamente sull'esperienza utente o quando si applicano rigorosi obiettivi di disponibilità durante i picchi di traffico.
Un'impostazione merita una seconda occhiata prima dell'inizio della stagione. I timeout degli hook del ciclo di vita sono impostati di default a 3.600 secondi e, se l'automazione legata a tale hook fallisce silenziosamente, le istanze rimangono bloccate in uno stato di attesa finché il timeout non scade, il che può bloccare lo scale-out durante il picco preciso che un team sta cercando di superare. Verificare quel valore predefinito rispetto ai propri script di distribuzione richiede pochi minuti. Scoprirlo durante un picco di traffico non lo è.
Lo scaling programmato e predittivo copre il divario che le policy reattive non possono colmare. Lo scaling programmato si adatta all'inizio di una campagna nota, mentre lo scaling predittivo aiuta quando il traffico segue schemi ricorrenti supportati da dati storici sufficienti. Nessuno dei due sostituisce il target tracking. Entrambi lo affiancano come base preventiva, in modo che la flotta sia già più ampia prima che il primo acquirente arrivi sulla homepage.
Le decisioni sui costi seguono la stessa logica. Un gruppo a istanze miste può combinare capacità On-Demand e Spot e attingere a più tipi di istanze, il che distribuisce il rischio se un tipo di istanza scarseggia. I Savings Plans riducono le tariffe di calcolo idonee ma non forniscono una prenotazione della capacità EC2, quindi uno sconto impegnato non è la stessa cosa di una garanzia che la capacità esisterà quando ne avrai bisogno.
Chi sente la pressione quando la capacità non è sufficiente
I grandi rivenditori con team di piattaforma dedicati tendono ad aver risolto questo problema con mesi di anticipo. La pressione ricade maggiormente sui piccoli e medi negozi online che operano su hosting condiviso, un singolo server web o un account cloud gestito in modo leggero. Questi sono i siti gestiti da una o due persone che si occupano contemporaneamente di marketing, inventario e infrastruttura.
La scelta della piattaforma determina quanto di questo carico ricada direttamente sul commerciante. Shopify ha riferito che i suoi commercianti hanno generato $6.2 miliardi in vendite online globali durante il Black Friday 2025, traffico che l'infrastruttura stessa della piattaforma ha assorbito, invece del singolo proprietario del negozio. Un negozio WooCommerce o Magento self-hosted deve gestire lo stesso picco di traffico senza quel cuscinetto condiviso; ecco perché le regole di autoscaling alla base di un sito autogestito sono ancora più importanti, e non meno, man mano che il volume degli ordini cresce.
Le agenzie e gli sviluppatori freelance che gestiscono diversi siti di clienti affrontano una versione composta dello stesso problema. Ogni sito potrebbe aver bisogno della propria soglia, della propria dimensione del warm pool e della propria finestra di scaling pianificata, sincronizzata con il calendario promozionale specifico di quel cliente.
Cosa mostrano le cifre del Black Friday 2025
La portata del problema è visibile nei numeri della scorsa stagione. I consumatori statunitensi hanno speso $11.8 miliardi online durante il Black Friday 2025, e i dispositivi mobili hanno rappresentato $6.5 miliardi di quel totale, ovvero il 55.2 percento delle vendite online, secondo Adobe. La maggior parte di quel traffico è arrivata tramite smartphone, spesso su reti mobili instabili, il che aumenta il costo di qualsiasi ritardo nella risposta della pagina.
La composizione del traffico sta cambiando in un modo che complica le previsioni. Adobe ha riferito che il traffico AI verso i siti di vendita al dettaglio statunitensi è aumentato dell'805 percento rispetto al precedente Black Friday. Si tratta di una nuova fonte di carico in rapida crescita che i modelli di traffico storici delle stagioni passate non catturano appieno, il che indebolisce le ragioni per affidarsi esclusivamente allo scaling predittivo senza un sistema di supporto reattivo.
I numeri a livello di piattaforma raccontano una storia simile sulla scala. I commercianti di Shopify hanno venduto per $14.6 miliardi durante il Black Friday e il Cyber Monday 2025, un aumento del 27 percento, servendo più di 81 milioni di clienti. Quel tasso di crescita supera la pianificazione della capacità anno su anno della maggior parte dei team, il che significa che il numero massimo di istanze dell'anno scorso è raramente la base sicura di quest'anno.
Cosa c'è in serbo per l'autoscaling durante le festività
I fornitori cloud stanno puntando sempre più sulla previsione piuttosto che sulla pura reazione. La funzione di scaling predittivo di AWS prevede la domanda in base a schemi storici e aggiunge capacità EC2 prima di un picco previsto, invece di aspettare che una metrica superi una soglia. La domanda aperta è se tale previsione possa tenere il passo con un mix di traffico che sta cambiando velocemente come lo shopping guidato dall'IA in questo momento.
I test rimangono l'elemento che i team saltano più spesso. I test di carico che aumentano gradualmente da zero al picco danno all'Auto Scaling il tempo di aggiungere capacità prima della domanda simulata, ma non convalidano il comportamento durante i picchi. Un test basato su una rampa graduale verrà superato brillantemente, lasciando comunque un sito esposto al tipo di picchi improvvisi e irregolari che il vero traffico festivo produce.
Se la stagione festiva del 2026 ripeterà il tasso di crescita del traffico AI visto nel 2025, o si stabilizzerà su un modello più costante, è il numero che ogni team di piattaforma terrà d'occhio nel prossimo ciclo di previsione.
