Uma empresa está desenvolvendo uma nova solução de machine learning na AWS. Os modelos são implementados como microsserviços independentes que baixam cerca de 1 GB de dados do modelo do Amazon S3 na inicialização e os carregam na memória. Os usuários acessam os modelos por meio de uma API assíncrona: eles enviam uma solicitação ou um lote de solicitações e especificam para onde os resultados devem ser enviados. Centenas de usuários usarão os modelos com padrões de uso irregulares — alguns modelos podem ficar ociosos por dias ou semanas, enquanto outros recebem rajadas de milhares de solicitações. Qual projeto um arquiteto de soluções deve recomendar para atender a esses requisitos?

A opção correta atende a todos os requisitos. O Amazon SQS desacopla a API dos modelos, lidando com padrões de uso irregulares e picos de solicitações. Os modelos, implementados como serviços Amazon ECS, podem baixar 1 GB de dados na inicialização e carregá-los na memória, o que é mais adequado para contêineres do que para funções Lambda. O Auto Scaling no ECS, baseado no tamanho da fila do SQS, garante que os recursos sejam provisionados apenas quando necessário, otimizando custos para modelos que podem ficar ociosos por dias ou semanas. As outras opções são menos adequadas: Invocar funções Lambda diretamente com 1 GB de dados na memória é inviável devido aos limites de memória do Lambda e ao tempo de inicialização (cold start) para baixar o modelo. Usar um ALB com ECS e SQS é redundante, pois o SQS já lida com a assincronicidade e o desacoplamento. O AWS App Mesh não é a ferramenta principal para escalabilidade baseada no tamanho da fila. Invocar funções Lambda por eventos SQS ainda enfrenta os desafios de memória e tempo de inicialização do Lambda para modelos de 1 GB. O Auto Scaling para vCPUs em funções Lambda não é um conceito padrão, o Lambda escala automaticamente com base na demanda.