Update auto-scaling by code pipeline using Cloud Formation Infrastructure as a Code

In traditional IT world, there are limited number of servers to handle the application load. When the number of requests increases the load on the servers also increases, which causes latency and failures.

Amazon Web service provides Amazon EC2 Auto Scaling services to overcome this failure. Auto Scaling ensures that Amazon EC2 instances are sufficient to run your application.

As demand grows supply lags behind, often leading to revenue loss. Auto scaling automatically scales your AWS cloud resources to meet demand.

You can specify desired capacity and auto-scaling policies for the Amazon EC2 auto-scaling. By using the scaling policy, auto-scaling can launch or terminate the EC2 instances depending on the demand.

During the heavy traffic in the application site the existing platform could not be scaled as efficiently. It also affects the business and not satisfied about the performance to spend ratio. This will lead to the outages for the e-commerce website. Rollout of the AMI manually leads to the outages.

Configuring the AGS manually with desired number of EC2 instances,

• Once the changes made in the application server.
• we are taking base image from the instance creating the launch template
• Proceeding to rolling update of AMI in auto scaling groups
• Elastic load balancing will help on this situation to maintain the loads between the EC2 Instances.

The procedure completely done with the manual intervention and rolling update of AMI also done manually for the applications.

Here we are providing the solution to overcome manual intervention, the ASG rolling with updates can be carried with the AWS Code pipeline along with the Cloud formation templates. The AMI is changed on the Code commit will leads to the AWS Continuous Integration and continuous deployment pipeline with or without the auto approval in the Code pipelines.

The code pipeline will be triggered once there change in the AMI ID and cloud formation stack will be triggered and based on the CPU utilization the instance count will be increased or decreased. The new instance launched, or the instance termination will be performed by elastic load balancing. This solution approach helped the business in a cost-efficient manner and there was no down time in the production site while launching or terminating the instance.

Auto Scaling Groups:

Using the auto scaling groups you can increase the number of instances to improve your application performance and you can decrease the number of instances depending on the load to reduce your cost.

Launch Template:

The launch template is an image template used by auto scaling group to launch EC2 instances. You can specify the Amazon Machine Image (AMI), instances type, key pair, and security groups etc. while creating the launch templates.

Scaling Policy:

Here we used Target tracking scaling policy, based on the target value for a specific metric, Increase or decrease the current capacity of the auto scaling group.

Elastic Load balancer:

Ec2 instances under the ASG is load balanced with the help of Elastic Load Balancer, Target group ARN is provided in the YAML Template to associate ELB with the ASG.

Code commit:

Cloud formation YAML templates are managed under the AWS Code Commit repository with version enabled.

Code Pipeline:

Once AMI changes in the Code commit, it will trigger the Code pipeline then Source stage will lead to the Approval stage finally will leads to the Code deploy.

Cloud formation:

Creation of Stack with the YAML template, it creates the resources which is mentioned in the template=.  If we want to modify/terminate the resources code templates are updated and it, make changes to resources.

YAML script has been saved in the code commit repository. The AMI ID was taken from the server from which the application team has done changes.

• Initially we will proceed with the new AMI ID in the stagging environment and once it is successful, we will then implement in the production environment.
• Cloud formation relates to IAM instance profile with Cloud Formation full access.
• Once the AMI has been updated in the code commit the code pipeline will be triggered and the cloud formation stack will start to update the resources.
• With the help of this CICD code pipeline we are automating the AMI rolling update in the auto scaling group without the manual intervention.
• In this process Autoscaling is performed along with the Elastic load balancing. The Instances will get initialized and terminated based upon the CPU utilization using target tracking policy.

• Roll back to the previous stage is easy
• High Availability
• Instances are scaled up and scaled down
• Cost savings
• Business hours impacts reduced
• No downtime while doing roll out of new application changes
• Approval mechanism can be implemented based on the requirement

If there is an issue with health check file and application code, We can easily rollback to the previous version of Launch templates.

The versions are maintained in the cloud formation as well as the code commits.

After implementing the CI/CD approach the applications are continuously live with out any impact on it. Cooling period of each and all instances are well managed based on the templates mentioned in the cloud formation stack.

The applications can provide better user experience (reduced latency) and able to scale and able to handle the business hours and non-business hours traffic in a cost-effective way.

New features are being rolled out seamlessly utilizing the CI/CD Process (CF and Code Pipeline). Reducing the risk of the downtime and provided the ability to rollback.

If you have any questions or suggestions, please reach out to us at contactus@1cloudhub.com

Written by:  Arunkumar K and Thamemul Ansari