Een applicatie die draait op EC2-instances in een Auto Scaling-groep verwerkt een groot aantal berichten uit een Amazon SQS-wachtrij. Het verwerken van een batch berichten duurde enkele uren en het gemiddelde CPU-gebruik van de Auto Scaling-groep overschreed de drempel van zijn target-tracking scaling policy niet. Applicatielogs worden naar Amazon CloudWatch Logs gestuurd. Je moet de wachtrij sneller verwerken met de minste operationele overhead. Welke optie voldoet aan deze vereiste?

De juiste optie is om metrische wiskunde te gebruiken in een target-tracking scaling policy. Dit is de meest efficiënte oplossing omdat het gebruikmaakt van bestaande CloudWatch-metrieken (ApproximateNumberOfMessagesVisible van SQS en GroupInServiceInstances van Auto Scaling Group) en deze combineert om een nieuwe metriek te creëren (berichten per instance) zonder extra Lambda-functies, abonnementfilters of EventBridge-regels te hoeven beheren. Dit minimaliseert de operationele overhead. De andere opties introduceren extra componenten zoals Lambda-functies en EventBridge-regels, wat de complexiteit en operationele overhead verhoogt. Het CPU-gebruik is geen goede indicator voor de verwerkingssnelheid van berichten, omdat de verwerking lang kan duren zonder hoge CPU-belasting.