Een bedrijf verwerkt berichten met een worker-applicatie die draait op drie EC2-instances in een Auto Scaling group die een simple scaling policy gebruikt. De workers halen berichten op uit een Amazon SQS-wachtrij. Sporadische pieken in berichten verminderen de verwerkingsprestaties en de SysOps-beheerder moet de Auto Scaling group schalen om een hoger wachtrijvolume aan te kunnen. Welke benadering voldoet het beste aan deze vereiste?

De beste benadering is om te schalen op basis van het aantal zichtbare berichten per instance. Door CloudWatch metric math te gebruiken om ApproximateNumberOfMessagesVisible te delen door het aantal instances in de Auto Scaling group, creëer je een dynamische schaalmetriek die direct reageert op de werkdruk in de SQS-wachtrij. Een target-tracking scaling policy kan dan worden geconfigureerd om dit gemiddelde te handhaven, waardoor de Auto Scaling group proactief schaalt wanneer de wachtrij groeit en krimpt wanneer de werkdruk afneemt. De optie om te schalen op de leeftijd van het oudste bericht is minder direct, omdat een hoog aantal berichten met een lage leeftijd nog steeds een hoge verwerkingslast kan betekenen. Het gebruik van een Application Load Balancer is niet relevant, aangezien de workers berichten direct uit SQS halen en niet via een ALB worden benaderd. Een scheduled scaling policy is niet geschikt voor onvoorspelbare, sporadische pieken.