How to Create an EC2 Instance Deployment Pipeline with AWS Auto Scaling Groups

This content is translated by Notion AI. Original content is written by a Korean.   

Overview

Hello, this article is a continuation of the previous article and describes an EC2 instance deployment pipeline using Auto Scaling Groups (ASGs).


This article covers the following topics.

  • What role do ASGs play in the EC2 instance deployment pipeline, and why might you want to use them?
  • Will modifying a Launch Template automatically deploy instances, or does it require additional work?
  • What API does Instance Refresh run through, and how is the pipeline logic organized?
  • How do the MinHealthyPercentage and MaxHealthyPercentage settings affect how instances are replaced?
  • What is the difference between the "Terminate and Launch" and "Launch and Terminate" methods, and what settings are required for non-disruptive service?
  • What is the difference between rollback using Desired Configuration and manually changing the Launch Template?
  • When should I use the Force Cancel Instance Refresh feature, and what should I be aware of?
  • What optimizations should I make to ensure a stable deployment pipeline?

What is the role of ASG in the EC2 Instance Deployment Pipeline?

The role of the ASG in the EC2 Instance deployment pipeline is to create new versions of EC2 instances and shut down existing instances. The ASG determines how EC2 instances are replaced based on the selected deployment strategy (Rolling update, Blue/Green, Canary).


The reason to utilize ASG in your EC2 instance deployment pipeline is that it provides many valuable features. The process of manually deploying EC2 instances is complex and challenging to automate, but ASG already supports many automation features that make pipeline configuration easy.

  1. Versioning support for EC2 instance configuration information
  2. Automated EC2 instance health checks
  3. Implement various deployment strategies, including RollingUpdate and Blue/Green.
  4. Can utilize auto scaling features
  5. Easy integration with ELB
  6. Support the rollback function


To use ASG in your deployment pipeline, you need to call the AWS AutoScalingGroup API.




Pipeline Logic

The pipeline logic is simple.

  1. Modify the launch template and raise the version.
  2. In ASG, update the launch template to match the version specified in step 1. To roll back while running, modify the launch template version in your desired configuration. Refer to the "How to Rollback" chapter of this article for more information.
  3. Deploy the instance by calling the ASG start-instance-refresh API.


The launch template manages your EC2 settings and provides versioning. This means that every time you change EC2 settings, a new version is created. The figure below shows the versions of the launch template.



ASG creates EC2 instances based on the settings in the launch template version. Modifying the launch template version means that EC2 instances are created based on the settings in that version.



It is important to note that modifying the launch template does not automatically deploy EC2 instances; you must manually run an instance refresh to apply the new settings.


You can refresh an instance by calling the AWS console or the AWS ASG API.

aws autoscaling start-instance-refresh \\
    --auto-scaling-group-name {ASG name}


If you want to roll back during an instance refresh, you need to set the Desired configuration. Modifying the launch template version finalizes it, preventing rollbacks. However, the Desired configuration represents the intended state, allowing rollbacks to the existing state.

aws autoscaling start-instance-refresh \\
    --auto-scaling-group-name {ASG name} \\
    --desired-configuration '{
      "LaunchTemplate": {
        "LaunchTemplateId": "lt-",
        "Version": "1" 
      }
    }'

The progress of the instance refresh can be easily checked in the AWS console.


When rolling back, you can also see the progress of the rollback in the AWS console.

 

How are instances replaced when an instance refresh is executed?

How are instances replaced when an instance refresh is executed? Will the new instance be created after all existing nodes are shut down? Or will the new instance be launched first, and then the existing nodes will be shut down?


The answer is that the way nodes are replaced depends on your settings. You can control the number of instances replaced by adjusting MinHealthyPercentage and MaxHealthyPercentage. Based on these settings, ASG calculates the minimum and maximum number of cases to keep when refreshing instances. According to AWS's official documentation, the formula for calculating the minimum and maximum instances is as follows.


For example, suppose your ASG is set up as follows

  • ASG Desired capacity: 1
  • MinHealthyPercentage: 90
  • MaxHealthyPercentage: 100
 aws autoscaling start-instance-refresh \\
    --auto-scaling-group-name {ASG name} \\
    --preferences '{
        "MinHealthyPercentage": 90,
        "MaxHealthyPercentage": 100
    }'


Since the Desired Capacity is 1, the maximum number of instances is 1. Desired Capacity × MaxHealthyPercentage/100 is calculated as 1 × 100/100, which equals 1. Therefore, when refreshing instances, the existing instance is shut down and the new instance is launched. ****This setup will cause a service failure in production, because none of the cases are running during the instance refresh. In the figure below, the existing instance is shut down, and the new instance is waiting to be created.


To refresh an instance without causing a service failure, you need a 'Launch and terminate' setting, where the new instance is created first and then the existing instance is terminated. The figure below illustrates how the Launch and Terminate settings function, for example, refresh. In this approach, the existing instance continues to run the service until the new instance is created, ensuring no failure occurs.


Suppose you're confused about the MinHealthyPercentage and MaxHealthyPercentage settings. In that case, you can calculate them with the help of the AWS console or use an AI tool like ChatGPT to set the appropriate values. The key is to ensure the instance refresh process doesn't cause service failures.


For a more detailed explanation of MinHealthyPercentage and MaxHealthyPercentage, check out the AWS blog post below.


How to invoke instance refresh in Terraform

There is a way to automatically refresh instances when modifying ASGs in Terraform: use the instance_refresh property of the aws_autoscaling_group resource.

resource "aws_autoscaling_group" "demo" {
  name                = "${var.project_name}-rolling-asg"
  
  instance_refresh {
    strategy = "Rolling"
    preferences {
      min_healthy_percentage = 50
      max_healthy_percentage = 100
      instance_warmup        = 30
    }
  }

How to roll back

There are two ways to roll back.


  • Modify the launch template and run an instance refresh

The first rollback method involves changing the launch template in ASG to the desired version and then running an instance refresh.


  • Call the rollback API

The second rollback method is to call the rollback API directly. This method requires you to set the desired configuration as a prerequisite. Desired configuration is a way to specify the launch configuration you want when refreshing an instance.

aws autoscaling start-instance-refresh \\
    --auto-scaling-group-name {ASG name} \\
    --desired-configuration '{
      "LaunchTemplate": {
        "LaunchTemplateId": "lt-",
        "Version": "1" 
      }
    }'

The main difference from setting the launch template directly is that the desired configuration can use the rollback API. The idea of a desired configuration is to change to a desired state, so if something goes wrong during deployment, you can roll back to the previous state. In contrast, changing the ASG launch configuration directly alters an already finalized state, making the rollback API unusable.


With the desired configuration, the Start rollback button is enabled, as shown below. This button calls the rollback API.


In addition, the desired configuration is written to the instance refresh history.


When a rollback is initiated, Instance Refresh immediately aborts any ongoing work and begins the rollback process. At this point, the instance refresh status changes to 'rollback in progress'.


When the rollback is complete, the rollback status changes to "Successful".



Canceling an instance refresh

The Force Cancel Instance Refresh feature was released in September 2025. This feature is available through the API or the AWS Console. Force Cancel Instance Refresh can be used when you make a deployment mistake or want to quickly cancel it.



One thing to keep in mind when force-canceling an instance is that the example with the changed settings will exist alongside the existing instance. As shown in the figure below, instances created with launch template versions 1 and 2 are running concurrently. Therefore, after force canceling, you need to run the instance refresh again as soon as possible.



Optimizing ASG for pipelines

The most critical factors for pipelines are reliability and rollback capabilities. If every run of a pipeline experiences a service failure, team members will be hesitant to deploy it and may eventually discontinue its use. It's also essential to be able to roll back immediately if something goes wrong.


Although I don't have extensive experience with ASG, my initial study suggests that optimizing the following areas is crucial.


  • Does the application shut down safely?

You need to ensure that applications running on your EC2 instance shut down safely when the instance is shut down. If you're familiar with the application, that's great, but most of the time you won't be, so you'll need to communicate with the developer to discuss how to shut down the application safely.


  • Instances run only one main application.

Running multiple applications on an instance increases the likelihood of bottlenecks, complicates debugging when issues arise, and adds more concerns to worry about during deployment, ultimately making you less likely to deploy. To avoid these complications, we recommend running only one primary application on an instance.


  • Reduce instance deployment time.

After an EC2 instance boots, it downloads and installs the files needed to run your application. This time increases deployment time, and over time, it creates unnecessary suspicion that something might have gone wrong. Therefore, it's a good idea to reduce instance deployment time as much as possible.


There are three main ways to reduce deployment time in ASG

First, create a golden AMI.

Second, time your health checks. ASG follows EC2 or ELB health checks, and you need to optimize boot-up time for health checks appropriately.

Third, how to tune instance_warmup, which is the instance refresh time. ASG only supports rolling updates as of 2025, and the instance_warmup field is the rolling update cycle time. If this time is unnecessarily long, your deployment time will increase accordingly.


Conclusion

In this post, we took a quick look at the EC2 instance pipeline using ASG. The ASG functionality is well-implemented, making pipeline configuration straightforward. The key, however, is to tune the options appropriately so that the pipeline doesn't cause service disruption.


Next time, we'll look at deployment strategies (Rolling Update, Blue/Green, Canary) utilizing ASG.


References

Comments

Post a Comment

Popular posts from this blog

When I use AWS Auto Scaling Group? and What is it?

Image
Overview This article summarizes the key features of AWS Auto Scaling Groups (ASGs ). ASGs manage EC2 instances as a group and are an AWS resource for managing EC2 instances, such as auto scaling or automatically replacing unhealthy nodes. This content is translated by Notion AI. Original content is written by a Korean.      In this article, we'll cover the following topics When do I use ASG? What is the difference between Launch Template and Launch Configuration, and which one is recommended to use? What do Desired capacity, Min capacity, and Max capacity in ASG mean, and what do they do? What is the difference between the 3 policies in Dynamic Scaling (Target tracking, Step scaling, Simple scaling)? How do each of the four instance management policies (Launch before terminating, Terminate and launch, No policy, Custom behavior) work? What is ASG rebalancing, and what should I be aware of? What are the features of Target Tracking Scaling, and what are the differen...
Read more »