Een bedrijf draait analysesoftware op Amazon EC2-instances die taken verwerken voor data die naar Amazon S3 is geüpload. Gebruikers melden dat sommige ingediende data niet wordt verwerkt. Amazon CloudWatch toont aan dat het CPU-gebruik van EC2 constant op of nabij 100% ligt. Het bedrijf wil de prestaties verbeteren en schalen op basis van de gebruikersbelasting. Wat moet een solutions architect doen?

De correcte aanpak is om Amazon SQS te gebruiken in combinatie met een Auto Scaling group. De hoge CPU-belasting en onverwerkte data duiden op een knelpunt in de verwerking. Door inkomende verzoeken naar SQS te routeren, wordt de verwerking ontkoppeld van de data-invoer, waardoor de applicatie asynchroon kan werken. Een Auto Scaling group die schaalt op basis van de SQS-wachtrijgrootte zorgt ervoor dat er automatisch meer EC2-instances worden opgestart wanneer de wachtrij groeit, en weer worden afgeschaald wanneer de belasting afneemt. Dit optimaliseert de prestaties en kosten. Het kopiëren van instances achter een ALB is geen oplossing voor de CPU-belasting; het verdeelt alleen de belasting over bestaande, overbelaste instances. Een S3 VPC endpoint verbetert de netwerktoegang tot S3, maar lost de CPU-bottleneck van de EC2-instances niet op. Het upgraden van het instancetype (verticaal schalen) kan tijdelijk helpen, maar is niet schaalbaar en kosteneffectief voor variabele workloads.