Una empresa está construyendo una nueva solución de machine learning en AWS. Los modelos se implementan como microservicios independientes que descargan aproximadamente 1 GB de datos del modelo desde Amazon S3 al inicio y los cargan en la memoria. Los usuarios acceden a los modelos a través de una API asíncrona: envían una solicitud o un lote de solicitudes y especifican dónde deben enviarse los resultados. Cientos de usuarios utilizarán los modelos con patrones de uso irregulares: algunos modelos pueden estar inactivos durante días o semanas, mientras que otros reciben ráfagas de miles de solicitudes. ¿Qué diseño debería recomendar un arquitecto de soluciones para cumplir con estos requisitos?

La opción correcta utiliza Amazon SQS para desacoplar la API de los microservicios, lo que es ideal para patrones de uso irregulares y procesamiento asíncrono. Amazon ECS es adecuado para modelos de ML que cargan 1 GB de datos en memoria al inicio, ya que permite contenedores con más recursos y tiempos de inicio más rápidos que Lambda para cargas grandes. AWS Auto Scaling en ECS (tanto para el clúster como para las tareas) asegura que los recursos se ajusten dinámicamente a la demanda, optimizando costos y rendimiento. Las opciones incorrectas fallan por varias razones: Invocar Lambda directamente con un NLB no es ideal para modelos de 1 GB, ya que Lambda tiene límites de memoria y tiempo de ejecución, y la carga inicial de 1 GB puede ser lenta. Usar un ALB con ECS y SQS, pero escalar con App Mesh, es incorrecto. App Mesh es para control de tráfico a nivel de aplicación, no para escalado de infraestructura basado en colas. Invocar Lambda con SQS y luego escalar las vCPUs de Lambda con Auto Scaling es incorrecto porque Lambda escala automáticamente según la concurrencia, no se le asignan vCPUs directamente, y los modelos de 1 GB son menos adecuados para Lambda.