AWS Deployment Strategies

When it comes to deploying new resources and code versions into your production environment, automation with minimal service interruption is ideal. A deployment strategy is important because it reduces manual configuration and tremendously improves serviceability, as well as reducing the amount of downtime during a deployment.

AWS offers several deployment strategies with its services, including but not limited to Elastic Beanstalk, CodeDeploy, ECS, and EKS. The three most common deployment strategies you will encounter are in-place, blue/green, and rolling. These deployment strategies are built into the AWS service and will aid you in deploying new applications in an automated, systematic manner. This guide will walk through how each of these three strategies works.

The blue/green deployment strategy creates two independent infrastructure environments. The blue environment contains the previous code or configuration, while the green environment contains the newest code or configurations. Traffic is then shifted to the newest environment (green) and diverted away from the previous environment (blue) by redirecting the DNS record to green’s load balancer using Route 53.

Since both environments have their own networks, the blue/green strategy has the benefit of being able to quickly and seamlessly roll back a deployment if failure is encountered. A downside of implementing blue/green is the uptick in cost due to running two infrastructure environments simultaneously.

Walk-through of Blue/Green Deployment:

In the first stage, traffic is directed towards the blue environment.

Then, after making a change in DNS, traffic is redirected to the green environment’s load balancer, which will serve the newest version of the application.

Unlike the blue/green strategy, in-place deployment uses the current infrastructure to deploy new versions of the application onto.

This deployment strategy is cheaper than blue/green because no new infrastructure is provisioned; however, there is a disadvantage to implementing this strategy. The con is that it will stop the application running on your infrastructure while deploying your newest code. If there are not enough resources to handle the downtime, you could potentially see a minor outage in your application.

There are ways to mitigate downtime. One example is by staggering the deployment so that there are enough infrastructure resources to handle demand. The second disadvantage to using the in-place deployment strategy is that it is slower to roll back because it changes if a failure arises. This is because the infrastructure has to be reverted, unlike redirecting traffic to the previous version’s load balancer in blue/green.

Walk-through of In-place Deployment:

As stated before, in-place deployment does not spin up a new infrastructure resource. It takes the current infrastructure and shuts down the application running on it before installing new code.

The next step of the process deploys new code onto the infrastructure and then starts the application again.

The deployment then repeats the process in Step 1, but on the next resource running Version 1 of the application.

Finally, once the new version of the application has been deployed onto every infrastructure resource, the deployment is complete.

The final deployment strategy is rolling deployment. This type of deployment completely replaces the underlying infrastructure, like in blue/green. Resources are taken offline one at a time and replaced with new resources running the latest version of an application.

The difference between the rolling and blue/green strategies is that in a rolling strategy, the infrastructure is not in a separate network or environment like in blue/green. Like in-place deployments, rolling deployments suffer from a risky rollback if issues occur during deployment. In order to mitigate outages, rolling deployments need other infrastructure resources to handle demand. A limited number of resources can be worked on at a time to prevent downtime.

Walk-through of Rolling Deployment:

A resource is taken down, as in an in-place deployment, but this time the newest version of the code is not deployed onto it.

A fresh resource created with the latest code.

The previous process repeats until all of the new resources have been deployed and are up and running smoothly.