Un'azienda esegue un'applicazione su istanze EC2 in un gruppo Auto Scaling dietro un Application Load Balancer (ALB). All'avvio, le istanze eseguono script user-data per scaricare contenuti applicativi critici da un bucket S3. Le istanze vengono avviate ma, dopo un certo tempo, vengono terminate con il messaggio: "An instance was taken out of service in response to an ELB system health check failure." Auto Scaling avvia e termina ripetutamente le istanze in un loop. L'unica modifica recente è stata l'aggiunta di una grande quantità di contenuti critici al bucket S3. L'azienda non vuole modificare gli script user-data in produzione. Cosa dovrebbe fare un architetto di soluzioni affinché l'ambiente di produzione possa essere distribuito con successo?

L'aumento del periodo di tolleranza del controllo di integrità del gruppo Auto Scaling (Health Check Grace Period) è la soluzione più appropriata. Questo periodo definisce il tempo in cui Auto Scaling attende prima di iniziare a controllare l'integrità di una nuova istanza. Poiché l'aggiunta di una grande quantità di contenuti a S3 ha aumentato il tempo necessario per il download e l'inizializzazione delle istanze tramite user-data, le istanze non sono pronte a rispondere ai controlli di integrità dell'ALB entro il periodo predefinito, causando la loro terminazione. Estendendo questo periodo, si concede alle istanze il tempo sufficiente per completare l'inizializzazione prima che l'ALB le valuti. Aumentare le dimensioni delle istanze EC2 potrebbe non risolvere il problema se il collo di bottiglia è il tempo di download da S3. Aumentare il timeout del controllo di integrità dell'ALB non è sufficiente se il periodo di tolleranza di Auto Scaling è troppo breve. Modificare il percorso del controllo di integrità dell'ALB non risolve il problema di fondo del tempo di inizializzazione.