Een bedrijf draait een interne, browsergebaseerde applicatie op EC2-instances achter een Application Load Balancer. De instances bevinden zich in een Auto Scaling-groep verspreid over meerdere Availability Zones. De groep schaalt op naar 20 instances tijdens werkuren en schaalt 's nachts af naar 2 instances. Medewerkers geven aan dat de applicatie 's ochtends vroeg erg traag is, hoewel deze tegen halverwege de ochtend goed werkt. Hoe moet de schaling worden aangepast om de klachten te verhelpen en tegelijkertijd de kosten laag te houden?

De juiste oplossing is het implementeren van een target tracking-actie die wordt geactiveerd bij een lagere CPU-drempel en de cooldown-periode verkort. Target tracking scaling past de capaciteit proactief aan om een gespecificeerde metrische waarde te handhaven, zoals CPU-gebruik. Door de drempel te verlagen, begint de Auto Scaling-groep eerder op te schalen, wat de traagheid in de ochtend verhelpt. Het verkorten van de cooldown-periode zorgt ervoor dat de schaalacties sneller worden uitgevoerd. Dit is kosteneffectiever dan een geplande actie die altijd naar 20 instances schaalt, omdat het alleen opschaalt wanneer nodig. Een geplande actie die de gewenste capaciteit instelt op 20 zou de kosten verhogen, omdat de instances mogelijk niet allemaal nodig zijn. Een geplande actie die de minimale en maximale capaciteit instelt op 20 is ook te rigide en kostbaar. Een step scaling-actie is reactiever en minder efficiënt dan target tracking voor het handhaven van een specifiek prestatieniveau.