Una empresa ejecuta un proyecto de 3 años con una aplicación que utiliza 20 instancias bajo demanda de Amazon EC2 registradas en un grupo objetivo de Network Load Balancer en dos zonas de disponibilidad. La aplicación no tiene estado y se ejecuta 24/7. La utilización normal de la CPU es de aproximadamente el 10%, pero la CPU aumenta al 100% durante períodos breves de alta actividad que duran unas pocas horas. Los usuarios informan de respuestas lentas. ¿Qué nueva arquitectura resolverá el problema de las respuestas lentas de la manera MÁS rentable?

La opción correcta es la más rentable porque combina Auto Scaling con instancias reservadas. El grupo de Auto Scaling ajusta dinámicamente la capacidad entre 4 (mínimo) y 28 (máximo) instancias, escalando hacia arriba durante los picos de uso para evitar respuestas lentas y hacia abajo cuando la demanda disminuye, optimizando costos. Comprar instancias reservadas para las 4 instancias mínimas reduce significativamente el costo base para la carga de trabajo constante. Las instancias bajo demanda se utilizan solo para la capacidad adicional necesaria durante los picos. Las otras opciones son menos rentables: Establecer la capacidad deseada en 28 y comprar RI para 20 instancias es costoso porque las 20 RI se pagan incluso cuando no se utilizan a plena capacidad, y las 8 instancias adicionales bajo demanda se pagan constantemente. Usar Spot Fleet con tipo de solicitud 'request' o 'maintain' y DefaultTargetCapacityType en On-Demand o Spot no es ideal para una aplicación 24/7 con picos predecibles. Las instancias Spot pueden ser interrumpidas, lo que no es adecuado para la capacidad base, y el tipo 'request' no mantiene la capacidad. Reemplazar el NLB con un ALB no es necesario para resolver el problema de rendimiento y añade complejidad.