I clienti caricano file su S3 e viene inviato un messaggio SQS contenente l'ARN dell'oggetto. Un worker basato su EC2 esegue il polling di SQS ed elabora i file; il tempo di elaborazione varia in base alla dimensione del file. Per ridurre i ritardi percepiti dal cliente, un amministratore crea un'AMI dall'istanza esistente e un launch template. Come dovrebbe essere configurato Auto Scaling per migliorare la reattività?

La risposta corretta è creare una metrica personalizzata basata su ApproximateNumberOfMessagesVisible e sul numero di istanze InService. Questo approccio consente di calcolare il backlog per istanza (messaggi visibili / istanze attive), fornendo una misura accurata del carico di lavoro per ciascun worker. Scalare in base a questa metrica personalizzata assicura che nuove istanze vengano aggiunte quando il carico di lavoro per istanza aumenta, migliorando la reattività. Le altre opzioni sono meno efficaci: Aggiungere diverse dimensioni di istanza e scalare in base a ApproximateNumberOfMessagesVisible non considera il carico per istanza e potrebbe non ottimizzare l'uso delle risorse. Scalare in base a ApproximateNumberOfMessagesDelayed non è l'obiettivo principale; si vuole prevenire i ritardi, non reagire ad essi. Creare una metrica personalizzata basata su ASGAverageCPUUtilization e GroupPendingInstances non riflette direttamente il carico di lavoro della coda SQS, che è il fattore scatenante principale per lo scaling in questo scenario.