Een applicatie draait op een Auto Scaling group van On-Demand EC2 instances achter een ALB. De workload bevat kritische analyses die geen onderbrekingen kunnen verdragen en snel moeten schalen, en niet-kritische analyses die onderbrekingen kunnen verdragen en geheugenintensief zijn. Je moet de scale-out latency voor de kritische workload verminderen en tegelijkertijd de niet-kritische workload verwerken. Welke combinatie van stappen voldoet aan deze vereisten? (Kies twee.)

De eerste correcte optie vermindert de schaallatentie voor de kritische workload door een warm pool van gestopte On-Demand instances te gebruiken. Gestopte instances starten sneller dan nieuwe instances, wat de schaaltijd verkort. On-Demand instances garanderen beschikbaarheid, essentieel voor kritische, ononderbroken workloads. Detailed monitoring is nuttig voor betere zichtbaarheid, maar niet direct voor latency. Spot Instances zijn ongeschikt voor kritische workloads vanwege mogelijke onderbrekingen. De tweede correcte optie isoleert de niet-kritische, geheugenintensieve en onderbrekings-tolerante workload in een aparte Auto Scaling group met Spot Instances, wat kosteneffectief is. Het configureren van een custom memory utilization metric via de unified CloudWatch agent is noodzakelijk omdat AWS geen ingebouwde CloudWatch metric voor geheugengebruik biedt. Door de applicatie aan te passen om twee target groups te gebruiken, kan de ALB verkeer routeren naar de juiste workload, waardoor de kritische workload niet wordt beïnvloed door de niet-kritische. Het vooraf gedefinieerde memory utilization metric type bestaat niet, wat de andere optie incorrect maakt.