Een bedrijf bouwt een nieuwe machine learning-oplossing op AWS. Modellen zijn geïmplementeerd als onafhankelijke microservices die bij het opstarten ongeveer 1 GB aan modelgegevens downloaden van Amazon S3 en deze in het geheugen laden. Gebruikers hebben toegang tot modellen via een asynchrone API: ze dienen een verzoek of een batch verzoeken in en specificeren waar de resultaten naartoe moeten worden gestuurd. Honderden gebruikers zullen de modellen gebruiken met onregelmatige gebruikspatronen — sommige modellen kunnen dagen of weken inactief zijn, terwijl andere duizenden verzoeken in bursts ontvangen. Welk ontwerp moet een solutions architect aanbevelen om aan deze vereisten te voldoen?

De correcte optie gebruikt Amazon SQS voor asynchrone verwerking, wat ideaal is voor onregelmatige en bursty workloads, omdat het verzoeken buffert en ontkoppelt. Amazon ECS is geschikt voor het hosten van microservices die 1 GB aan modelgegevens in het geheugen laden, omdat het meer controle biedt over de runtime-omgeving en geheugenconfiguratie dan Lambda. AWS Auto Scaling op basis van de SQS-wachtrijgrootte zorgt ervoor dat ECS-services en het onderliggende cluster efficiënt schalen om de vraag aan te kunnen en kosten te optimaliseren. Incorrecte opties: NLB met Lambda: Lambda is minder geschikt voor het laden van 1 GB aan modelgegevens bij elke aanroep, wat opstarttijden (cold starts) zou verlengen en kostbaar zou zijn. NLB is bovendien niet ideaal voor asynchrone API's. ALB met ECS en SQS, met App Mesh voor schaling: Hoewel ECS en SQS goed zijn, is App Mesh primair voor service-to-service communicatie en observatie, niet voor autoscaling op basis van SQS-wachtrijgrootte. ALB is ook niet ideaal voor asynchrone verzoeken. SQS met Lambda en Auto Scaling van vCPU's: Lambda's vCPU's kunnen niet direct worden geschaald op basis van SQS-wachtrijgrootte; Lambda schaalt automatisch op basis van het aantal gelijktijdige aanroepen. De 1 GB modeldata maakt Lambda minder efficiënt.