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

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 differences in behavior during scale-out and scale-in?
  • When should I use Instance refresh, and how do I do it with AWS APIs?

Background on writing this article

I started my career with Kubernetes, so I used to think that deploying applications only happened on Kubernetes, but recently I've realized that you need to choose the right deployment environment for the right situation, and I've been using Kubernetes less and less.

I recently had an application that I decided was a good fit for AWS ASG, so I thought I'd take this opportunity to summarize the key features of ASG.

There's not much difference between ASGs and Kubernetes, as the concept of deployment is the same, it's just that I haven't used ASGs much and am not familiar with them yet.


What is an Auto Scaling Group?

ASGs create groups of EC2 instances to manage EC2 instances efficiently. By grouping them together, you can easily manage multiple identical EC2 instances with a single setup.



When should I use ASG?

In my opinion, there are four situations where ASGs are a good idea.


1. When you need to create more than one identical EC2 instance.

ASG can create n EC2 instances with the same settings at any time. If you don't use Auto Scaling, you need to create n EC2 instances, but ASG only needs to set the number of EC2 instances.


2.When to auto scale EC2 instances

The Auto Scaling setting allows ASG to automatically adjust the number of EC2 instances when certain conditions are met. To implement these features without ASG, you would need to develop the relevant logic yourself or utilize additional services such as Lambda.


3. If you need to write an EC2 instance deployment pipeline

ASG has the ability to deploy new EC2 instances through the ASG API. You can utilize this ASG API to automate the deployment of EC2 instances. EC2 instance deployment options include creating a new instance and removing an existing instance (Rollingupdate), removing an existing instance and creating a new instance, and so on.


4. When you need to automatically replace an unhealthy EC2 instance

ASG replaces an unhealthy EC2 instance when it is discovered. EC2 instances often become unhealthy due to network, disk, and other reasons, which require human intervention to resolve or replace the EC2 instance.


ASG Benefits

The benefits of ASG are well documented in AWS's "ASG benefits" document.


In this article, we have already covered the main benefits of ASG in the "When to use ASG?" chapter, but one important benefit that is missing is availability.


When ASG creates EC2 instances, it spreads them evenly across multiple Availability Zones (AZs). This ensures that your services can continue to operate even if a particular AZ fails. However, it is not optimal to deploy EC2 instances across multiple AZs in all situations. Moving data between AZs incurs network costs, so you might want to use only a single AZ if you need to minimize costs.


ASG rebalancing

ASG checks the AZ distribution of existing running EC2 instances and performs rebalancing if they are not evenly distributed. I don't have much experience with ASG yet, so I haven't personally experienced rebalancing, but I understand it as a phenomenon similar to EKS Karpenter consolidation, where nodes are frequently swapped out regardless of intent. This means that if your application doesn't have a guaranteed graceful downtime, ASG rebalancing can cause it to fail.


If you are concerned about the possibility of failures due to ASG rebalancing, you should set the rebalancing action you don't want in the Suspended Processes option. For example, to disable AZ rebalancing, you can set "Suspended Processes=AZRebalance".


How do I set up an EC2 instance managed by ASG?

To create an EC2 instance, you need a VPC subnet, EC2 instance profile, Security Group, AMI, etc. How do I manage these settings?


There are dedicated AWS resources to manage EC2 instance settings. These are the Launch Template and the Launch Configuration. The ASG defines how EC2 instances are managed, including managing the number of EC2 instances and setting auto scaling policies.


As mentioned earlier, you can configure EC2 instances in either Launch Template or Launch Configuration. If you have to choose one or the other, we recommend Launch Template unless there's a specific reason. Launch Templates offer more features than Launch Configurations, such as versioning.


The figure below shows an example of an ASG using Launch Template to set up an EC2 instance.


The figure below shows that you can set versions in a Launch template.


As shown in the figure below, Launch templates are very similar to the options you set when creating an EC2 instance. In the launch template, you can set AMI, EC2 instance type, key pair, VPC subnet, Storage, Security group, user data, etc.



How do I set the number of EC2 instances in ASG?

The number of EC2 instances managed by an ASG is set to the Desired capacity. ASG adjusts the number of EC2 instances according to the set Desired capacity.

In addition to the Desired capacity, there are Min and Max capacities, which are used for Auto Scaling.


How do I set up Auto Scaling in ASG?

Auto scaling is when ASG automatically adjusts the Desired capacity based on your scaling settings. You need to set a policy for how you want to adjust the Desired capacity.

There are three types of auto scaling in ASG

  • Dynamic scaling: Adjusts the number of instances based on real-time conditions. It uses CloudWatch metrics and CloudWatch alarms as scaling criteria.
  • Predictive scaling: Analyzes historical data to predict the number of instances needed in the future. We use machine learning to analyze data from the past 14 days to predict demand for the next 48 hours every hour.
  • Scheduled actions: Set up schedules in advance to adjust the number of instances at specific times.



ASG sets upper and lower limits with min and max values to prevent the Desired capacity from increasing or decreasing indiscriminately when Auto scaling is enabled.

  • Desired capacity: Current number of EC2 instances
  • Min capacity: The minimum number of EC2 instances that should be maintained when Auto Scaling is running.
  • Max capacity: The maximum number of EC2 instances that can run when Auto Scaling is running.


The most popular scaling is Dynamic scaling. Dynamic scaling has three scaling policies

  • Target tracking scaling: Scaling based on CloudWatch metrics.
  • Step scaling: Scales based on CloudWatch alarms and allows you to set multiple criteria (steps).
  • Simple scaling: Scaling based on CloudWatch alarms.



Target Tracking Scaling calculates the Desired Capacity required to achieve the target by itself. The user only needs to set the CloudWatch metric to be checked against and the Target value for that metric. If the current metric is greater than the Target value, ASG calculates the Desired capacity and adjusts accordingly. It aggressively increases the number of EC2 instances when the Desired capacity is increased, but conservatively decreases it when the capacity is decreased.


ASG instance management policies (e.g., replacing unhealthy nodes)

ASG detects the unhealthy state of an EC2 instance and replaces it with a new EC2 instance. This ability to replace unhealthy nodes is part of the Instance Maintenance feature. The rules that are applied when replacing an instance are called Instance Maintenance Policies. These policies are also applied when running an Instance refresh.

There are four instance management policies in total.

  • Launch before terminating: Create new EC2 instances and remove existing ones afterward.
  • Terminate and launch: Remove the existing EC2 instance and create an EC2 instance.
  • No policy: Launch before terminating when rebalancing is enabled, and Terminate and launch in other situations.
  • Custom behavior: You manually set which EC2 instances to terminate and which to create.


The example below shows how ASG detects and replaces an abnormal instance. We used no policy for the instance management policy. As you can see in the figure, ASG first created new EC2 instances and then removed the existing unhealthy instances.




How do EC2 instances deployed with ASG work with ELB?

ASG can work with AWS Network Load Balancer and Application Load Balancer (ELB). When you integrate ASG with an ELB, all EC2 instances created by ASG are automatically connected to the ELB.



When you associate an ASG with an ELB, you associate it with a Target Group, not directly to the ELB. EC2 instances created by the ASG are automatically added to this Target Group and associated with the ELB. It is important to note that you must implement proper health checks to ensure that the EC2 instance passes the health checks in ELB. If the instance does not have proper health checks implemented, the ELB health checks will consistently return an unhealthy status, which will disrupt operations.




How can I relaunch an instance deployed with ASG (Instance refresh)?

To relaunch an EC2 instance, you need to use the instance refresh feature in ASG, which literally replaces the instance. In this process, the method of replacing the instance follows the instance management policies, which can be set separately as needed.


Instance refreshes can be executed via AWS API calls or from the AWS console.

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


Instance refresh is often used in a deployment pipeline utilizing ASG. We'll cover deployment pipelines next time.


What's next

In this hour, we covered the key concepts and features of ASG. Next time, we'll take a deeper dive into instance refreshes and specifically look at deployment pipelines utilizing ASG.


References

Comments

Post a Comment

Popular posts from this blog