Un'applicazione viene eseguita su un gruppo con scalabilità automatica di istanze EC2 On-Demand dietro un ALB. Il carico di lavoro contiene analisi critiche che non possono tollerare interruzioni e devono scalare rapidamente, e analisi non critiche che possono tollerare interruzioni e sono ad alta intensità di memoria. È necessario ridurre la latenza di scale-out per il carico di lavoro critico, elaborando al contempo il carico di lavoro non critico. Quale combinazione di passaggi soddisfa questi requisiti? (Scegliere due.)

La prima opzione corretta riduce la latenza di scale-out per il carico di lavoro critico utilizzando un warm pool di istanze stopped. Questo permette alle istanze di essere pronte più velocemente rispetto all'avvio da zero. L'uso di istanze On-Demand garantisce che le analisi critiche non subiscano interruzioni, poiché le istanze Spot possono essere revocate. Il monitoraggio dettagliato fornisce dati più granulari per lo scaling. La seconda opzione corretta isola il carico di lavoro non critico in un gruppo Auto Scaling separato, consentendo l'uso di istanze Spot per ridurre i costi, accettando la possibilità di interruzioni. L'installazione dell'agente unificato CloudWatch e la configurazione di una metrica di utilizzo della memoria personalizzata sono essenziali per scalare in base all'utilizzo della memoria, poiché questa non è una metrica predefinita per EC2. L'ALB e i due target group permettono di instradare il traffico in modo appropriato. Le opzioni errate: L'uso di istanze Spot per il carico di lavoro critico è sbagliato perché non può tollerare interruzioni. I lifecycle hook non riducono la latenza di scale-out, ma gestiscono il ciclo di vita dell'istanza. L'utilizzo di una metrica di utilizzo della memoria predefinita è sbagliato perché non esiste una metrica predefinita per l'utilizzo della memoria di EC2.