There are primarily two main approaches to updating your stack—the in-place and Blue-Green approach. Each of these approaches has their own pros and cons, and you should select the approach that is most suitable for your specific situation. You can also start with one approach and then move to a different approach depending on your business needs.

As the name suggests, the in-place updates approach requires you to create a new template and then use that template to update your existing stack by using the update stack API. This approach is faster, more cost-efficient, and the migration of data and application states is much simpler than with the Blue-Green approach.

In the Blue-Green approach, you take the new template and create a completely new and separate stack (from your currently running stack). After you have verified that the new stack is running as per your requirements, you switch production traffic over to it. The main steps in a Blue-Green deployment are illustrated in a series of figures here.

Instances within the production stack are labeled Blue and the instances hosting the new stack are labeled Green. The Blue fleet is currently serving all of the production traffic:

Verification and acceptance tests for the new stack are conducted on the Green fleet while the Blue fleet continues to serve the production traffic:

After the acceptance tests are successfully cleared, the production traffic is switched over to the Green fleet:

The Green fleet is then labeled Blue and is serving all of the production traffic. The fleet that was originally Blue is now labeled Green:

The primary advantage of the Blue-Green approach is that you are not touching the currently running stack at all. You also have the option to fallback to the old stack at any time, easily. However, Blue-Green deployments are expensive, as this approach requires you to spin up a duplicate set of instances. The success of this approach is also highly dependent on the thoroughness of your acceptance tests. In addition, the DNS switch can create issues as DNS clients are not well behaved and require ELB warm-up. 

There are several variants of the Blue-Green approach that address some of the shortcomings of the traditional Blue-Green deployment approach discussed previously.

An approach that uses a mix of the Green and Blue instances (with a single ELB) may be useful for certain applications, and is described here.

The starting state is a single fleet of instances labeled Blue (belonging to an Auto Scaling group). These instances are serving all of the production traffic:

In this stage, you create a new instance hosting the new stack (in a separate Auto Scaling group with a maximum size of 1). While the Blue fleet is serving a majority of production traffic, the Green instance also starts serving some of the production traffic:

In the next step, you scale up the Green fleet:

Finally, you switch over to the Green fleet:

At this stage, you can shut down the Blue fleet and your Green fleet is now the designated Blue fleet. This approach takes into consideration that acceptance tests may not be complete or comprehensive. At the same time, there are no DNS changes or ELB warm-ups required.

A variant of the Blue-Green approach that works well within an Auto Scaling group is rolling updates. The updates are applied to the instances in batches (with zero downtime). CloudFormation ensures that there is always a set of healthy instances serving your customers at all times. In this approach, the Auto Scaling group is divided into several batches, and then the update is applied to the first batch of instances. ELB health checks should be enabled to ensure that the instances are healthy after the update has been applied. If the instances in the batch are healthy, then you can signal back to CloudFormation to update the next batch of instances. These rolling updates, across all your instances, can be achieved using a single CloudFormation template.