Hello and welcome to this short lecture which will discuss a number of options that are available for your Elastic Beanstalk application deployments. Having an understanding of the different options that are available enables you to efficiently manage your infrastructure. Now Elastic Beanstalk provides the following deployment options. All at once, rolling, rolling with additional batch, and immutable. Let's assume you already have an environment created with an application deployed across a number of instances that are being managed by Elastic Beanstalk. With that in mind, let me explain how each of these deployments work, starting with all at once. 

All at once deployment is the default choice if you don't specify any other option. If you needed to update your application within your Elastic Beanstalk environment. Using the all at once option will simply roll out the application to your resources all at the same time. And this would, of course, cause a disruption to your application while the update was in progress, which would, in turn, affect your end users. 

Rolling, with a rolling deployment you are able to minimize the amount of disruption that is caused when using the all at once approach. When performing a rolling deployment, Elastic Beanstalk will deploy your application in batches, performing an update to just a portion of your resources at a time. Once the update is complete it will then perform the update on the next batch. This would mean that you have two different versions of the application running at the same time for a very short period. However, it also means that you can still serve requests and process information through your application while the deployment is gradually rolled out for your infrastructure. 

Rolling with additional batch. The rolling with additional batch is much the same principle as rolling. Your environment is updated in batches until all your resources have the new update. However, with rolling deployments there is an impact to your available resources while the update is being applied. For example, let's say during a rolling deployment Elastic Beanstalk creates four different batches. While the update is being applied, your application availability takes a 25% hit while one batch is being updated. With rolling with additional batch, Elastic Beanstalk adds another batch of instances within your environment to your resource pool to ensure application availability is not impacted. So in this case, your deployment would have five batches. And while the update was being applied to one of your existing batches, you would still have four remaining batches of instances maintaining operation. On completion of the update to all batches, Elastic Beanstalk would then terminate this additional batch of instances. 

Immutable, immutable deployments will create an entirely new set of instances in parallel to your existing and older resources. These new instances will be served through a temporary autoscaling group behind your elastic load balancer. This means for a short period of time your environment would essentially double in size. However, once your new instances are deployed and have passed all the health checks the old environment would be removed and the autoscaling group updated. If your health checks fail for the new instances then Elastic Beanstalk would terminate them and delete the autoscaling group and traffic would continue to be served to your original environment. 

That has now brought me to the end of this lecture. Coming up next I will provide a demonstration on how to configure Elastic Beanstalk.