Answer - D.
The AWS Documentation mentions the following.
Immutable updates are an alternative to rolling updates where a temporary Auto Scaling group is launched outside of your environment with a separate set of instances running on the new configuration, which are placed behind your environment's load balancer.
Old and new instances both serve traffic until the new instances pass health checks.
The new instances are then moved into your environment's Auto Scaling group and the temporary group and old instances are terminated.
All other options are invalid since it clearly mentions that the current environment should not be changed.
For more information on updating environments, please refer to the below URL.
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environments-updating.html
Note:
Rolling updates have downtime.
However, it is not for the entire infrastructure.
It will be divided into batches.
AWS Docs says that "When a configuration change requires instances to be replaced, Elastic Beanstalk can perform the update in batches to avoid downtime while the change is propagated.
During a rolling update, capacity is only reduced by a single batch size, which you can configure.
Elastic Beanstalk takes one batch of instances out of service, terminates them, and then launches a batch with the new configuration.
After the new batch starts serving requests, Elastic Beanstalk moves on to the next batch."
To make configuration changes to an Elastic Beanstalk environment with minimal downtime and deploy the code only to new instances, you would consider using the Rolling with Additional Batch deployment mechanism.
Here's an overview of each of the four deployment mechanisms available in Elastic Beanstalk:
A. All at Once: This deployment mechanism deploys the new version of your application to all instances at once. It's best used for applications that can tolerate some downtime, such as non-critical internal applications. This deployment mechanism may not be suitable for applications with a large number of instances or applications that have critical dependencies.
B. Rolling: This deployment mechanism deploys the new version of your application in batches, one batch at a time. Each batch of instances is taken out of service while the new version is deployed, and then returned to service once the deployment is complete. This deployment mechanism is best used for applications that can tolerate some downtime, but not as much as the All at Once deployment mechanism.
C. Rolling with Additional Batch: This deployment mechanism is similar to the Rolling deployment mechanism, but it includes an additional batch of instances. The new version of your application is deployed to the first batch of instances, which are taken out of service and returned to service once the deployment is complete. Then, the second batch of instances is taken out of service and the new version is deployed to those instances. This deployment mechanism is best used for applications that need to minimize downtime, as it ensures that at least one batch of instances is always available to handle traffic.
D. Immutable: This deployment mechanism deploys the new version of your application to a completely new set of instances, leaving the old instances in place. Once the new instances are running and have passed health checks, traffic is shifted from the old instances to the new instances. This deployment mechanism is best used for applications that require zero downtime, as it ensures that traffic is always handled by a healthy set of instances.
Based on the requirement to minimize downtime and deploy the code only to new instances, the Rolling with Additional Batch deployment mechanism would be the best choice. This mechanism ensures that at least one batch of instances is always available to handle traffic while the new version of the application is being deployed to the other batches of instances.
