Un'applicazione in esecuzione su istanze EC2 in un gruppo Auto Scaling elabora un volume elevato di messaggi da una coda Amazon SQS. L'elaborazione di un batch di messaggi ha richiesto diverse ore e l'utilizzo medio della CPU del gruppo Auto Scaling non ha superato la soglia della sua policy di scaling di target tracking. I log dell'applicazione vengono inviati ad Amazon CloudWatch Logs. È necessario che la coda venga elaborata più velocemente con il minimo overhead operativo. Quale opzione soddisfa questo requisito?

L'opzione corretta soddisfa il requisito di elaborare la coda più velocemente con il minimo overhead operativo utilizzando una policy di scaling di target tracking basata su metriche matematiche di CloudWatch. Questa soluzione calcola direttamente il numero di messaggi per istanza combinando ApproximateNumberOfMessagesVisible di SQS e GroupInServiceInstances di Auto Scaling Group. Questo approccio è efficiente perché CloudWatch esegue il calcolo delle metriche matematiche nativamente, senza la necessità di funzioni Lambda o EventBridge, riducendo l'overhead operativo e la latenza. Le opzioni che coinvolgono AWS Lambda introducono complessità e costi aggiuntivi per la gestione della funzione, la sua invocazione (EventBridge o filtri di log) e la pubblicazione di metriche personalizzate, che non sono necessarie dato che CloudWatch può eseguire il calcolo matematico direttamente. L'opzione che usa un filtro di sottoscrizione CloudWatch Logs per invocare Lambda non è adatta per monitorare lo stato di una coda SQS, ma piuttosto per elaborare i log.