AWS introduced autoscaling to make EC2 cluster scaling easier. We've seen users constantly make changes to their EC2s and put new policies into play. It’s important to update your Autoscaling group with the new instances so that it doesn’t ignore these machines. AMI updates keep the AutoScaling Groups aware of the changes in instances. When you add new code to your EC2 instance and you need to make sure your existing instances and new instances are both using it, you’ll need an AMI update. There are two means of achieving this.

• Update the AMI template that the AutoScaling Group uses, and then force each live EC2 instance to update itself with the new AMI template. New EC2 instances will use the updated AMI template. The steps to do this are on this page, below.
• Write a startup script that will run when a new EC2 instance spawns. The startup script can for example grab your latest code and deploy it to itself.

Most people would prefer it if the AutoScaling Groups automate the update when a new AMI is launched. Currently, DevOps engineers spend time writing Lambda functions to achieve this. 

Current steps include:

• Create an IAM role for AWS Lambda
• Create an AWS Lambda function
• Create an Automation document, patch the AMI, and update the Auto Scaling group

The Lambda function will handle instance termination and launch will update the AMI and patch it onto the ASG.

With automation becoming the forefront of cloud management, we’ve seen a number of users request this use case or template. Scripting just remains time-consuming, especially when dealing with repetitive tasks that contribute to operational governance. 

Now, workflows can reproduce the result without the time constraints brought up when setting up the lambda function and automation document. Using a visual interface, you can perform the AMI creation, template launch, and autoscale update together - with a single workflow. 

You can also integrate Jenkins and other CI/CD software with the workflows so you won’t have to write your automation scripts. Improve the customization capabilities with further integrations. You can update the AMIs based on the different integrations and then in turn update the autoscaling group afterward.

Let’s say you have a development pipeline and during your iterations, you add additional EC2 machines for higher CPU performance. With our workflow integrations, you can automatically update the autoscaling to include the new machines with new AMIs, keeping your development pipeline uninterrupted.

Process

The workflow replicates the entire process of updating your Autoscaling Groups, in a way it mimics human actions. The trigger runs every day to check for updated instances. The nodes, then launch the autoscaling template with the new AMI. The autoscaling group updates the new and existing instances with the new AMI. Afterward, the old EC2 instances are terminated.

Step 1: Trigger

Runs every day and launches based on the changes to the instances.

Step 2: Auto Scaling Group

Loads the autoscaling group.

Step 3: Filter

Filter out the updated instances by tag.

Step 4: Resources

Loads the instances of the auto-scaling group.

Step 5: Filter

Compares the instances of the trigger with the instances of the auto scaling group to determine which requires the creation of AMI.

Step 6: Create AMI

Step 7: Launch Template

Launches the template based on created image with the auto scaling group. 

Step 8 : Update Auto Scaling Group.

Conclusion
Many other use cases can be translated similarly to our workflows. It’s a matter of combining the resources accurately. The building blocks that we’ve laid out with our platform can be used in any number of ways with zero coding. If you have a resource you wish to simplify, try to use our workflows to your advantage.