Una empresa implementó una aplicación en AWS Elastic Beanstalk y estableció la capacidad deseada del grupo de Auto Scaling del entorno en cinco instancias EC2. Si la capacidad cae por debajo de cuatro instancias durante las implementaciones, el rendimiento de la aplicación se degrada. El entorno utiliza la política de implementación all-at-once. ¿Cuál es el cambio MÁS rentable para evitar el problema de rendimiento durante las implementaciones?

La política de implementación all-at-once reemplaza todas las instancias simultáneamente, lo que puede causar una interrupción o degradación del servicio si el número de instancias cae por debajo de un umbral crítico. Cambiar a rolling with additional batch (implementación continua con lote adicional) permite que Elastic Beanstalk lance nuevas instancias antes de terminar las antiguas. Al establecer el tamaño del lote adicional en 1, se asegura que siempre haya al menos una instancia adicional disponible durante la implementación, manteniendo la capacidad deseada de cinco instancias y evitando que el rendimiento se degrade. Cambiar la capacidad deseada a seis instancias aumentaría los costos sin resolver la causa raíz del problema durante las implementaciones. Traffic splitting (división de tráfico) es más complejo y costoso, y un tiempo de evaluación de 1 hora podría prolongar la degradación. La política rolling (continua) sin un lote adicional aún podría reducir la capacidad operativa durante la implementación si el tamaño del lote es demasiado grande o si las instancias fallan al iniciar.