Automated Blue/Green deployment using Lambda and CloudFormation

Blue/Green deployment is a well-known method to deploy an application without any downtime. Performing DNS switch is one of the very common techniques to achieve this. Using DNS switch has a minor issue with DNS caching which might take some time for DNS change to be propagated.

Apart from DNS switch, AWS gives us two different options to switch the stacks. One is to have single ELB and swap it across auto-scaling group and another is switching the launch configuration of the auto-scaling group. Check the following presentation on various methods to achieve blue/green deployment in AWS.

I preferred swapping the ELB between auto-scaling groups. This method is fairly simple and also gives the advantage of no changes to DNS entry. Using Lambda it becomes quite easy to perform this task as a part of CFN, by just selecting the stack that needs to be live.

Following Lambda function gets the 3 parameters from the CFN (Live ASG, Non-Live ASG & ELB Name), attaches the ELB to Live ASG & detaches it from the Non-Live ASG.

Lambda function which performs the switch.

IAM permissions required for the Lambda function.

Following CFN stack enables you to select the stack that should be live and the capacity for each stack. Once the stack is switched: let’s say make green as new live-stack, validate whether everything looks good, just update the CFN stack and change the values of ASG capacities for blue (old) stack to 0 and it automatically terminate the instances and save costs.

Expand for CloudFormation template.

 

 

2 Comments

 Add your comment
  1. if you deploy using elastic beanstalk you should use the “swap urls ” feature which is designed for blue/green deployments.

    • Yes, EB does provide the SWAP URL feature which performs the DNS switch and it have a small delay in propagating based on ISP’s DNS caching as mentioned in the beginning of the post.

      We can also use CFN alone (without Lambda) directly to switch the ELB across auto-scaling gorups but currently CFN will replace the ASG completely for any changes in the ASG hence it will launch new instances and take sometime for it to perform.

      Whereas the above approach helps to validate whether the new stack is fine and then perform the switch instantaneously. Multiple approaches provides us an opportunity to decide which is best suited for the specific use case.

Leave a Comment

Your email address will not be published.