Una empresa ejecuta una aplicación de comercio electrónico en instancias de Amazon EC2 que almacenan los detalles de las compras en un clúster de base de datos de Amazon Aurora PostgreSQL. Los clientes experimentan tiempos de espera de la aplicación durante el uso pico. Un arquitecto de soluciones debe rediseñar la arquitectura para que la aplicación pueda escalar a la demanda pico de la manera MÁS rentable. ¿Qué combinación de acciones debe tomar el arquitecto? (Elija dos)

La opción de configurar un grupo de Auto Scaling de nuevas instancias EC2 para reintentar las compras y actualizar las aplicaciones para usar Amazon RDS Proxy es correcta porque RDS Proxy gestiona de manera eficiente las conexiones a la base de datos, reduciendo la sobrecarga de conexión y mejorando la escalabilidad de la aplicación, especialmente durante picos de tráfico. Los reintentos de las instancias EC2 aseguran la resiliencia del procesamiento. La opción de actualizar la aplicación para enviar solicitudes de compra a una cola de Amazon SQS y configurar un grupo de Auto Scaling de nuevas instancias EC2 que lean de la cola de SQS es la otra respuesta correcta. SQS desacopla la aplicación del procesamiento de compras, absorbiendo picos de demanda y permitiendo que las instancias EC2 escalen de forma independiente para procesar los mensajes de la cola, lo que es rentable y elástico. Configurar ElastiCache solo abordaría la lectura de datos, no el procesamiento de compras. Usar una función de AWS Lambda para reintentar las compras podría ser costoso y menos adecuado para cargas de trabajo persistentes que Auto Scaling. API Gateway con un plan de uso no aborda directamente la escalabilidad del procesamiento de la base de datos o la aplicación backend.