Un'azienda gestisce un'applicazione web su una singola istanza EC2 che diventa lenta nei momenti di picco quando l'utilizzo della CPU supera il 95%. Uno script user-data installa pacchetti personalizzati sull'istanza al momento dell'avvio, il che fa sì che l'avvio dell'istanza richieda diversi minuti. L'azienda creerà un gruppo Auto Scaling utilizzando un launch template, con tipi di istanza misti, capacità di CPU variabili e un limite di capacità massima. L'azienda desidera ridurre la latenza dell'applicazione quando vengono avviate nuove istanze durante gli eventi di scaling. Quale approccio soddisfa questo requisito?

L'opzione corretta prevede l'uso di una policy di scaling dinamico, warm pools e lifecycle hooks. Una policy di scaling dinamico (ad esempio, basata sull'utilizzo della CPU) reagisce ai cambiamenti di carico per scalare le istanze. I warm pools mantengono un pool di istanze pre-inizializzate e pronte all'uso, riducendo significativamente il tempo di avvio delle nuove istanze durante gli eventi di scaling. I lifecycle hooks consentono di eseguire lo script user-data (o altre azioni di pre-inizializzazione) mentre l'istanza è nel warm pool, prima che venga messa in servizio. Questo assicura che l'applicazione sia completamente pronta quando l'istanza viene aggiunta al servizio, riducendo la latenza. Le altre opzioni sono meno efficaci: Le policy di scaling predittivo sono ottime per carichi prevedibili, ma non risolvono il problema del tempo di avvio lento delle istanze. L'impostazione del tempo di warmup a 0 secondi non risolve il problema dello script user-data che richiede tempo per l'esecuzione; anzi, potrebbe peggiorare la situazione mettendo in servizio un'istanza non pronta. L'uso di una policy di manutenzione dell'istanza per lo script user-data non è una funzionalità standard di Auto Scaling e non è il meccanismo corretto per questo scopo.